DEV Community: Viraj Chavan

What I learned from my first ever software development internship

Viraj Chavan — Sat, 25 Jan 2020 07:11:55 +0000

I was a student at an engineering college in India. After 3 and a half years years of learning computer science academically, I now had a chance to test my knowledge in the real world through an internship.

In this article, I’ll be sharing my internship experience at Josh Software, Pune with the hope that it will be helpful to other IT and computer engineering students that are looking for internships.

Like most of my colleagues at the college, I had a very limited view about software development in general and didn’t know what to expect from an internship.

Lucky for me, I was assigned a live project, which was based on Ruby on Rails, something that I had already developed an interest for.

After I had learned PHP and MySQL in the 2nd year of my studies, I built a basic web app, and all that it did was some CRUD (Create, Read, Update, Destroy) operations. I remember talking with a friend who had similar skills to mine, and said “Even we can build Facebook now that we know PHP and MySQL!”

How ridiculously simple things seemed at that time. Now I understand how complex building/maintaining a software can be.

So here’s what I learned from my Internship while working on a live project.

General lessons

Scale Makes a huge difference

How many users are going to use the software?
How much data will be processed?
What are the expected response times for a function?

These are questions that we, as college students, hardly think about. Our college projects were usually short-sighted. In real-world projects though, the above questions fundamentally affect decisions about hardware, technologies/tools to be used, system architecture, algorithms, and so on.

Working with a large codebase

Back in college, we used to work on projects that had like 15 - 20 files or so. Built in under a week, the whole project could be understood in a few hours.

Now the project I’m working on has hundreds of files spread across dozens of folders. It can take months to understand the whole project, and hours to debug a bug that’s spread across multiple files. And the first time you look at the whole project directory, you don’t know where to start understanding the code.

Writing maintainable code

Knowing that the code you write will be read, understood, and improved/changed by someone else (or even yourself) in the future makes you write code that’s maintainable.

In college, all I focused on was getting the expected functionality to be complete, and never considered whether the code I wrote was maintainable.

This resulted in scrambled pieces of code that somehow worked at the time. But two days later even I wouldn’t understand why I had written a certain piece of code that way. And changing some part of the code almost always broke other parts. 😆

Code Maintainability is easier to recognise by its absence, like when something you thought should take an hour ends up taking a week.

Using a version control system - properly

When I first started building small software, all the files existed on my own development machine, and maybe they were backed up to Google Drive as regular files.

Then I got to know about GitHub, but I merely used it as a safe storage place for my code. I used the GitHub desktop app to commit all changes on just the master branch. I even hesitated using it through the command line.

Now not a day goes by that I don’t use Git. It’s such a great tool for collaboratively writing code, distributed development, branching out for new features, pull requests, and so on.

Here’s a little article on why version control systems are awesome!

The importance of using a Test Driven Development approach

During my internship, I was assigned to work on a new feature that was to be added to the main project .

I wrote the code and tested if it was working the way it was supposed to. It worked perfectly, or so I thought. I deployed the feature to the production confidently, and moved on to work on something else.

After a few hours, Rollbar, a real time error reporting tool burst with a number of errors in our code deployed to production. I checked the errors and they seemed unrelated to anything I had ever worked on.

After some debugging, all of those errors traced back to a single method. A method that was called in numerous places, and in which I had modified just a single line, and hadn’t checked where else it was used.

Now this could’ve been avoided if the code that used that method had test cases written for it, and if I had checked if all the test cases ran successfully before deploying the code. That made me realize the importance of test driven development.

Here’s an article to understand why writing test cases is important.

Things specific to Web Development

The MVC Architecture

Back in my college days, when I developed applications in PHP, I had no clue what Model, View, and Controller were. Any project was so complexly scrambled that I couldn’t find in which file a piece of important logic was written. The HTML embedded PHP scripts at odd places and I had placed all the files in just one folder.

Then I learned about the Rails framework, and got accustomed with the MVC architecture.

Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components - Model, View, and Controller. Each of these components are built to handle specific development aspects of an application (source)

MVC really simplifies things and is an important part of many major frameworks.

Dealing with Databases

In the last 6 months, I haven’t written a single direct SQL database query. Yet I deal with databases everyday, even doing some complex operations. This is thanks to the ORM (Object Relational Mapper) that Ruby On Rails uses.

ORMs convert object-oriented programming language such as Ruby into database lingo in which to perform operations. Which makes data access more portable and abstracted from the required database queries that are necessary when manipulating data.

Thanks to ORM, it’s much much easier to query the database. This gives a big advantage to beginners, who can start writing applications without even knowing SQL.

Writing/Using REST APIs (Application Programming Interfaces)

APIs make it easier for one application to talk to another.

APIs make some other applications’s functionalities easily accessible to our application. For example, I once developed a Road Trip Planner application that used the Google Maps API to show various places on a map that a user could visit on a particular route.

APIs can also be used to separate the front-end and the back-end completely. For example, we can write the back-end as an API-only Rails application that can be used by a web site, an Android/iOS application, or even some third party applications.

Using ElasticSearch for searching

Although I don’t know much about ElasticSearch so far, but I’ve learned that it’s a NOSQL, distributed full text database. It acts as a distributed search engine that is incredibly easy to scale and returns results at lightning speed.

Why would we need it for searching? Because having millions of records in a regular database can make it really complex to make efficient searches.
With Elasticsearch, we can index the documents needed to be searched and it can perform queries across all those millions of documents and return accurate results in a fraction of a second.

Elasticsearch has a Restful API, which makes it really easy to query the searches and get the results.

Here’s a tutorial that helped me, and here are some use cases of Elasticsearch.

Using asynchronous/background tasks

Sometimes the user will perform an action on our application that takes a considerable amount of time to complete. We don’t want the user to sit there waiting for this action to complete, so we send it off to a background worker.

Here’s a link that explains it better.

In Ruby On Rails, I came across Sidekiq, which makes it easy to handle background tasks efficiently.

Thanks for reading! If you found this article helpful, give me some claps. 👏

There’s still a long way to go!

Check out my website at https://virajc.tech

(Originally published on Medium(25-07-2018): https://medium.com/free-code-camp/what-i-learned-from-my-first-ever-software-development-internship-701aa756a72f)

Search your website directly from Chrome’s Omnibox

Viraj Chavan — Sat, 25 Jan 2020 05:30:10 +0000

You might have searched for YouTube videos directly from Chrome’s Omnibar.

You start typing youtube.com and the Omnibar shows a little message: Press Tab to Search YouTube

And when you do press the Tab key, it lets you search YouTube directly, without needing to visit the site.

Some websites also show you the search suggestions provided by them instead of the default search engine’s suggestions.

Wikipedia providing its own search suggestions

Ever wondered if you can implement the same for your own website? Turns out, it’s quite easy!

Here’s how.

1. Create a search results page

First, your website needs to have a page which can show search results for a query. (You already might have one).
For example,
http://yourwebsite.com/search?q={searchTerms}

How you handle search queries and show the results is completely up to you.

2. Define where your searches should be directed

To tell the browser that your website can accept search queries through the search bar, you just need to write a simple XML file.

The most important part of the document is this tag:

<Url type="text/html" method="get" template="http://yourwebsite.com/search?q={searchTerms}" />

This is the URL the browser will redirect the search queries to. When the user presses enter in the Omnibox the string {searchTerms} in the url is replaced with the string the user typed.

3. Let the browsers know

On your site’s homepage, provide a link to the file you created. Place it in the head of the html file. For example:

<head>  
 <link type="application/opensearchdescription+xml" rel="search"  
       href="/url\_of\_xml\_file"/>  
</head>

And that’s it!

With this setup, your website is searchable through Chrome’s Omnibar.

Do note that Chrome enables it for a website only after user visits the website for the first time. It also adds the website as a Search Engine Provider in its settings as an option.

4. Enable search suggestions

To make things better, we can show some search suggestions as the user types the search query. Let’s implement that as well.

First, create a suggestion service on your website which will accept a search query and return suggestions.

It should always return a JSON array of results, with the first result being the original search query.

For example, if I hit the API [https://yourwebsite.com/suggestions?q=g](https://yourwebsite.com/suggestions?q=cat,)it , the response should be a valid JSON array like ['git', 'github', 'gitlab', 'git commands', 'github login']

Now add this tag to the XML document we created:

<Url type="application/x-suggestions+json" method="get" rel="suggestions" template="http://yourwebsite.com/suggestions?q={searchTerms}" />

The omnibox will now use your suggestion service to provide query suggestions based on the user’s partial query.

The XML file we created is called an OpenSearch description document. A specification for such functionality is created by OpenSearch. It has defined simple formats which the browsers can implement.

So ideally this should work on all browsers! Although the way browsers implement this visually may be different. For example, Firefox implements it in a separate search bar next to its address bar.

How Firefox implements OpenSearch

The document we created was the bare minimum needed for this example. For more details, see the detailed specification.

References

Thanks for reading!

Find me on Github/LinkedIn.

JavaScript tip: How to properly isolate your code using Anonymous Closures (IIFEs)

Viraj Chavan — Sat, 25 Jan 2020 05:19:43 +0000

JavaScript code can get really messy when we keep adding random functionalities as the requirements come.

And most of the times, any new functionality you add to an app should not interfere with the existing code in your app.

You don’t want the new piece of code to override your existing variables/functions accidentally. When such code causes some unexpected behaviour, it can get really annoying to debug through multiple files.

To achieve this, our new code should run in an isolated environment. In JavaScript, closures can help us do that. Closures are the primary mechanism used to enable data privacy in JavaScript.

This is how an anonymous closures looks like:

(function () {  
    // ... all vars and functions are in this scope only.  
    // still maintains access to all global variables  
}());

Just put your code inside of this function, and it will have its own scope while keeping the global scope pollution-free.

This is also known as a Self-Executing Anonymous Function or Immediately Invoked Function Expressions (IIFEs).

Variables declared inside the closure are not accessible outside it, but it still can access/create global variables. (The use of global variables should ideally be avoided though, they are known to be evil.)

All of the code that runs inside this function lives in a closure, which provides privacy and state throughout the lifetime of our application.

If we need to, we can expose variables/methods by returning them in the function.

var result = (function () {  
    var name = "Harry";   
    return name;   
})();

console.log(result); // "Harry"  
console.log(name); // "error, 'name' not defined"

JavaScript Closures is the main idea behind the Module Pattern in JavaScript, you can explore the basics of module patter here:

http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html

https://dev.to/tomekbuszewski/module-pattern-in-javascript-56jm

Find me at https://virajc.tech

The World of Charts in Web Development (Part 2)

Viraj Chavan — Sat, 25 Jan 2020 05:05:01 +0000

Do read the Part 1 before this one, if you haven’t yet.

In Part 1, we discussed about rendering graphs on the server-side v/s client-side, and the 2 ways to render graphs on a web page: SVGs and HTML5 Canvas. Now let’s take a look at some client-side JavaScript libraries that we can use to render different types of charts on our front-end.

Some of these are open source and some proprietary. While open source libraries are free to be used and modified as we like, they are often not as feature-rich as some if its paid counterparts. Open source libraries may also not provide reliable support on issues you may face during development.

If data visualizations is a critical part of your application, then it may make sense to use a paid solution.

D3.js

D3 is probably the most flexible and powerful data visualization JS library ever! It allows great control over the final visual result. It’s also probably the most difficult to get started with.

D3 allows us to programmatically create SVG objects, style them, and add transitions, dynamic effect. One needs to spend quiet some time learning its concepts before being productive in it. There’s a course on Udacity that teaches D3Js.

D3 does not use Canvas to render the elements. It strictly uses SVG to give a greater control over everything.

D3 is widely used (89k + stars on Github). In fact there are lots of libraries that use D3 to create new libraries on top of it, making it more accessible.
Following libraries are built using D3:

Since D3 is a lower level library and intended more as a supporting layer for higher-level visualization tools, you may not use it directly unless what you’re building is very unique and can’t be achieved by simpler higher level libraries.

ChartJs

ChartJs is a popular JavaScript data visualization library. It uses Html5 Canvas to render elements on the screen. The designs of the charts are simple and responsive with limited options to customize looks and features.

It provides basic data visualization types of charts such as Line, Bar, Doughnut, Pie, Scatter etc. It’s very easy to get started with, takes little time to learn how it works.

The features of the library are simple and will be enough for most use-cases one might come across. Although it is not very customizable for complex custom features.

If you want to use ChartJs with a frontend framework, wrappers for ReactJs, VeuJs, Angular etc are available to make things easy.

Chartist

Chartist is another open source library that uses SVGs to create responsive data visualizations.

You can use CSS to style the elements the way you want. You can event add some animations using CSS. This makes Chartist more configurable than ChartJs.

Chartist is way simpler to get started with since it follows the principle ‘convention over configuration’ and provides may types of charts out of the box. It also has some wrapper-libraries in React/VueJs to make development easier.

HighCharts

HighCharts is a popular premium library for creating customizable, interactive charts of any complexity. It is free for personal/non-commercial use, but you’ll need to buy a license for any commercial use.

It uses SVG and fallbacks to VML for backward compatibility all the way to IE6/IE8.

It provides rich functionality with minimal configuration. The results are often premium, well tested visualizations. The charts will be mobile-optimized, responsive, browser-compatible, exportable and more.

It is very well documented and any issue you face during development is likely to be solved through its community/support.

AmCharts

AmCharts is a commercial feature-rich JavaScript library. It’a a simple yet powerful and flexible library. It is also free for personal use, but you’ll need to pay for a license for commercial use.

It also uses SVG to render charts in the browser, which makes it highly configurable. It offers a variety of charts out of the box that offer great design and functionality.

It is easy to get started with, with good documentation and customer support.

Fusion Charts

Fusion Charts offers a wide variety of charts out of the box. It has over 95+ types of charts to work with. You’ll need to buy a license to use their library.

It offers great documentation, support for plugins, smart defaults, exportable charts, UX elements for interactivity, browser compatibility and more.

Unlike most other libraries, it also offers official support for server-side rendering of graphs through FusionExport SDK!

It has officially-supported plugins for major front-end frameworks such as React and VueJs. It also comes with customer support for solving your problems during development.

Google Charts

Google Charts are powerful, free and simple to use. Developers can create the most basic charts using Google Charts. It uses SVGs to render charts in the browser.

Although suitable for most requirements, it does not offer as extensive set of features as its paid counterparts such as HighCharts. Google Charts have reasonable defaults, but can also be customized in countless ways

Google itself uses this library for its data visualization needs across products.

Thanks for reading! Let me know if you liked the article in the comments!

Find me at https://virajc.tech

The World of Charts in Web Development (Part 1)

Viraj Chavan — Sat, 25 Jan 2020 04:55:13 +0000

The best way to make sense of lots of data is through visualizations. Want to know how the stock price of Facebook has changed over the past 1 year? Why spend time looking at the numbers when there’s a line chart to look at!

A variety of chart types exist to satisfy any data visualization needs you might have. As a web developer, you’re sure to have come across a requirement to show a chart on a web-page that represents dynamic data.

Now, you can try to render a chart from some dynamic data all by yourself. But why reinvent the wheel when lots of people have already worked hard to do it for you!

There’s a plethora of chart libraries you can use. Some are paid. Some are open source. Some are highly powerful. Some are minimal but also easy to use. Which one should you use?

But first, let’s understand how a chart can be rendered on a web page?

Server-side rendered charts

Although rarely used, we sometimes may need to generate our charts on the server and then deliver them to the user.

A common use case for this is when we want to show some charts in the dynamic emails we send to users through the back-end. Since JavaScript execution is not allowed in the HTML emails, we can generate image files for the charts and render them in emails. (Other use-cases might include creating embedded charts in PDF files, attaching images in emails etc)

There are limited libraries available for server-side chart generation. Different libraries are available for most server-side languages. Separate services like image charts and quickchart.io also exist, which give you a REST API to use.

If you can’t find a server-side library that fits your needs, as a workaround, you can write a script on your server that uses one of the client-side libraries to create the chart in HTML. Then you can convert the html to PDF or an image file on the server.

Client-side rendered charts

This is the most common use-case. Before learning about libraries that do this, let us first look at how you would implement it yourself.

There are two ways you can render a chart in modern web applications: SVGs and HTML 5 Canvas. Some libraries out there offer both canvas and SVG renders. Others tend to stick with just one of the two options.

Using SVGs

SVG (Scalable Vector Graphics), is an XML-based graphic format with the ability to infinitely scale without losing the image quality. It has a DOM, letting you reference any graphical elements individually using JavaScript. Which lets you do cool things such as attach event handlers to an element on the chart. You can also use CSS to style elements.

SVG shines when you want a high quality graphic that is resolution-independent. It does not loose its quality on large resolutions.

While having every element available in the DOM is beneficial, for large data-points, the performance of the SVG-rendered chart falls short. Performance degrades logarithmically as the number of elements increase.

Using HTML5 Canvas

Canvas is a pixel based element in HTML. The Canvas element is simply a large XY grid of pixels and gives the developer freedom to decide what and how to render things on it using JavaScript.

Canvas uses a “fire and forget” model, there is no DOM that can be referenced once an element has been drawn.

Canvas is quite fast in rendering large number of data points. In fact, people use have built games with lots of graphics and animations using Canvas. Although as the size of the screen increases, the performance may degrade as more pixels need to be drawn. Which makes its performance resolution-dependant.

When to use which: SVG v/s Canvas

Highly customizable elements for limited data: SVG
Zoomable graphics without loosing quality: SVG
Visualizations for large amount of data: Canvas
When large real-time data processing is required: Canvas

Here’s an in-depth discussion on the pros and cons of both: SVG vs canvas: how to choose. You don’t need to know this to use any of the libraries, but it’s always good to know how it works underneath in an abstract way.

In Part 2, we discuss popular client-side JavaScript data-visualization libraries.

Thanks for reading! Find me at virajc.tech.

References:

https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/samples/gg193983(v=vs.85)#html5-graphic-technologies