Blog Archives

Working around untrusted certificate errors in Express JS

A few very common fatal errors thrown by the request module for express while trying to access data from self-signed web servers are Error: DEPTH_ZERO_SELF_SIGNED_CERT and UNABLE_TO_VERIFY_LEAF_SIGNATURE

This is because of which mandates NodeJS to validate a server’s certificate by default, which needless to say is how things should be in a production environment.

However, more often than none we tend to use self-signed SSL certificates in our development environments or even within internal networks.

Thankfully for such brain-wracking moments, two particular flags come to our rescue. Enter strictSSL and rejectUnauthorized. The way I personally like to use these flags, is to set defaults within my development environments as follows to bypass SSL validation hence, saving the day! 🙂

var request = require('request').defaults({
    strictSSL: false,
    rejectUnauthorized: false

Please do note, that I do not recommend that you ever try this on your production systems without understanding the true implications of what disabling strictSSL and rejectUnauthorized means for you node server. By disabling these, you are essentially telling your server to skip validation of the requested server’s identity, which leaves your application in quite a vulnerable position.

Using Vim to generate HTML output of code

This is an interesting bit that I learnt about from an email in a mailing list by James Pryor.

To generate html output for code within a shell script you can use:

vim '+syntax on' '+ set nu' '+set background=light' +TOhtml '+w myscript.html' '+qall!'
If you don’t want numbers and need a dark background you can use:
vim '+syntax on' '+ set nonu' '+set background=dark' +TOhtml '+w myscript.html' '+qall!'

Installing EditorConfig on Sublime Text

To install Editor Config on Sublime Text all you need to do is to follow the following steps:-
  1. Go the Preferences tab -> Package Control.
  2. Select Install Package from the drop down menu.
  3. Wait for the list to load, once it loads it will show you a list of packages.
  4. Now, type in EditorConfig and select the highlighted option.

To confirm that Editor Config is installed correctly on your Sublime Text instance you can go to Preferences -> Browse Packages. If installed correctly you should be able to see an EditorConfig directory present in the Packages directory.

That’s it! Enjoy! 🙂

Coding Best Practices – With a tinge of CSS!

For the curious: What made me write this post:

A very good friend of mine called me up today and asked me to go through a web portal that their company is developing to gather some feedback about it. When I opened the page I was quite impressed at first site and everything about the visual styling to the page layout frankly looked quite awesome.

Being a web developer myself, I somehow couldn’t resist the urge of opening up the browser’s developer tools to check out code behind it, and this is where the problems started showing up. As soon as the developer tools window pane opened up eating up half of my screen estate, I noticed the page layout completely fall apart. There was a mess of overlapping texts, visual elements, and what not all over the page rendering the site completely useless.

By instinct I ended up opening the style editor of developer tools to check the CSS to find out where things where breaking, however what I saw was nothing but plain horror for any front-end developer . It had to be one of the most messed up style-sheets I have ever seen! Basically it was nothing but a garbled up mess of style definitions for classes, ids, media queries, etc. What made it even more insane was that there was no homogeneity to the way the document was written, no indentations and to top it all the whole site had the most generically confusing class names that one could ever have nightmares of.

So, I called up my friend to congratulate him about having such a gem of a front end guy work on his team, when I came to know about the most sorry part of the whole story. The person who wrote this code was apparently a man who had quite a large number of years worth of “industry experience” and has been doing front end work since before even I knew what HTML/CSS was!

This is what convinced me to go ahead and post a few simple things about things that one should keep in mind while writing code with a bit of an inclination towards CSS.

For the Restless, Here’s what I want to say:

Here are a few best practices that I personally follow that I’d like to share with everyone:-

  • Always remember that any code that you write has a high probability of being extended or needing maintenance in the long term. 70% of most maintenance woes can be avoided by keeping this simple fact in mind while writing code.
  • As a direct consequence of this, make sure that whatever code that you write is readable even to the most novice coders out there.
  • Adopt good variable naming practices [eg. a variable name “count” is always more desirable than a variable name “i” for a counter variable since it’s name gives a good idea about it’s functionality.]
  • Try and write self documenting code, with enough [read: not too less, yet not too much] comments describing what a certain block of code does, and how it does that. The best way to make sure that the comments are of the perfect length would be to make sure that the comments for a block of around 5-10 lines of code is never longer than 2 lines [of 80 characters each].
  • One of the places which very often make the biggest mistakes in documenting stuff are the CSS files. A CSS file with a spaghetti mixture of ids, classes, etc. is never a good idea.
  • Always try to have a proper document structure for the CSS with logical grouping of style definitions, preferably with an index comment at the very beginning. This helps make the code more readable and thus much more easy to maintain and extend in the long run.
  • Indentation is your biggest friend – It helps make the code more easily readable as well as create a well-structured document format. Indentation makes it dead simple to understand the flow of logic within the program and separated different logical groups from each other by creating well nested content for the document.
  • Lastly, and more importantly before signing off a piece of code as ready for production, be honest to yourself and ask yourself: “Is this the kind of code that I would like to read through and work upon in a few years time when I have forgotten the minutes of the implimentation?”

I sincerely this helps atleast a few people to understand what it is like to write beautiful code and give them a brief idea about how to do so themselves.

Programming on Mobile Devices

This is a thought that’s been rather bugging me for sometime now:

Is writing code (programming) via mobile devices really not a very feasible idea?

In the current scenario, almost all conventional programming is done on desktop computers (PCs, laptops and the likes), wherein we have a standard keyboard which is used to write down all the code, and a relatively large enough display device to help us visualize what we are writing. However, with the mercurial rise in popularity of mobile devices we have seen a huge shift from conventionally used devices to mobile devices with almost all major aspects of modern day computing making a gradual yet steady shift towards mobile computing.

We see a lot of developers now focusing on “Programming for mobile devices“, however there is an evident lack of focus on “Programming on mobile devices“, which is actually quite weird in my honest opinion. On one hand we are talking about a truly mobile world, where almost every aspect of computing is being made available for on the go mobile devices. Whereas, on the other hand, for the very basic necessities for enabling these mobile functionalities we fallback to traditional computers (and by traditional, I do take into account laptops as well, because no matter how small in size they may be, they still follow the same desktop oriented norms).

Why is it so that we aren’t yet completely comfortable with the thought of being able to write a piece of code on our mobile handsets? I know some people may argue that it is possible to write code in some ABC language using a XYZ software on a tablet device. However, what I ask is that are you really comfortable with the current scenario? Why can’t we find a nice alternative way to make programming on devices such as mobile handsets more intuitive, organic, comfortable and developer friendly?

The main problem with devices as small as mobile handsets as I see it, is a combination of low resolution / small screen size + lack of a comfortable keyboard / input device. But is it really the main challenge that we are talking abut here? Or is our mindset the main challenge? Is it really that difficult to take on the challenge of redesigning the existing programming methodology and create an efficient solution for mobiles, or is it just that we are just too lazy and or narrow minded to explore the possibilities of programming on mobile devices.

I have heard the proverb which says “Nothing is impossible“, however, I think there’s an even more dangerous public opinion which states “This is not feasible!” which generally results in the eventual death of ideas. But is feasibility really applicable here or should it be the willingness and openness in one’s mind to imagine and realize the things which others might reject as non-feasible and bring about a much needed change in the paradigms? What do you think? Please do leave your thoughts on this as comments below.

%d bloggers like this: