Radix Default for parseInt()

So, recently I see that parseInt() now defaults to radix of 10 in most modern browsers. However, it is still best practice to specify the radix when using parseInt() because you can’t guess the browser the user is on. I used to get burned on this gotcha with something like


The default radix used to be octal which would make code snippet’s output 0.

It is great that the default is now radix 10 but best practice is to always specify the radix.

Directory Convention for AngularJS

AngularJS helped open up new challenges while I spent the last year developing with it.  Some of the following main challenges occurred:

  • Too many components such as directives, controller, factories, services, and filters are created within one script file.  The many lines of code cause a maintainability issue.
  • Components are applicable across modules but the question would come on how to organize them.

Some people who work with Angular will resort to Angular’s seed repository which groups components into their own file.  For example, all controllers will going into one controller.js file.  I find this is suitable for less complex application’s where filters, for example, crammed into one file but the lines of codes are at a minimum.  Instead of the seed approach, I decided to take Brian Ford’s approach on modularizing your code.  His blog post states to separate each item of each component group to its own file.  So, say you create a new filter that title case’s text called “titleCase”.   Then, you would create a file called titleCase.js.  To add to this, you would want to place this file in a folder called “filters” just as Brian’s blog shows.  All filters, controllers, services, factories, and directives are added using the angular.module() without the second string array parameter that specifies dependencies.

/*The following would be how you add the 'titleCase' filter to the 
'myApp' module without chaining. Notice the lack of 
second parameters for module dependencies. */


Brian’s post describes creating the module as a file in the root level of the javascript folder.

/*Creating a new module call myApp with a dependency to another module, someOtherModule.*/
angular.module ("myApp",["someOtherModule"]);

I found serious benefits in this approach:

  1. You will be dealing with less lines of codes per file.
  2. If you follow the stack trace, the isolation of errors are clearer because you have both a file name and line number of a specific component versus a line number and file name of a consolidate file of multiple types of the same component (e.g., ten different controllers in one controller.js).

However, what if we can expand on the isolation of code.  When I used this method, I found that one “filter” folder can have many filter files but not all of them will necessary share the same module. So, I added to this convention by making a common module with the following for use by all modules.  The following shows all of the common module’s components under the app folder (located in the js folder).  This module could be considered the core functionality in which your app’s code chooses to take what it needs from it



I used the underscore prefix to designate it as the base foundation module for my application.  Anything I consider to have a common use and is not coupled to a specific business use case will be placed inside these folders.  Also, at this directory level, I will place my index.js file (this naming convention is my preference) that defines my main module (e.g., myApp).  I do not bootstrap my app in this file because I leave ngApp to do it or explicitly do it in a code block below the references to these files.  This is a matter of preference.

Now, that we have this foundation module completed, I can add more page or business logic-specific modules.  I designate these modules to a specific context.  For example, if I had a page for managing users of a website, I would create a module for that call Users.  My above image shows two modules: moduleA and ModuleB.  Each module, like the root module, will have an index.js that defines the module.  These modules will actually have a dependency on the the root module.  This was done so that each module can reuse components provided by the base module.  So, if we were to look at moduleA’s index.js code, we would see something like.

/*definition of moduleA*/

Now, moduleA will have access to the base module myApp’s components.  The same can be said for moduleB.  However, both moduleA and ModuleB are unaware of each other.

Notice one important thing:  each module has its own component folders!  This isolates these component solely to the module they share the parent folder with.



From this point forward, copy one of the module folders along with its components and modify it for a new module.  This convention can help in a recursive file search for any concatenation/minification/obfuscation tools like ASP.NET MVC 4’s Bundler or Ruby on Rails asset pipeline. An example structure can be seen at my github repo.  You can use it to guide you on this convention.

Securing ELMAH’s sensitive information

If you have done ASP.NET, you may have incorporated ELMAH, a great of a tool for logging information and providing a dashboard to view it. As you can see in the following information, you get a nicely presented dashboard to page through and review any errors in full detail. It is a few steps above a regular trace.axd.

However, such information is a treasure trove for black hats. At my current job, there are a few applications that use ELMAH but the problem I see is that none of them have the security configured for production.  For each application, I was able to typed elmah.axd after each sites’ URL root, hit Enter, and see every error the application logged. Also, I was able to see what IIS version, authentication type used, and, worst of all, the users’ usernames! Since my discovery, I notified my colleagues of what the public facing ELMAH dashboard and referred them to the security configuration page to help them disabled remote access. The ELMAH site has a page on how to secure ELMAH. The page’s information will tell you how to shut off remote access by simply setting the ELMAH configuration node security’s attribute allowRemoteAccess to “1”. You could incorporate this change in your web.release.config for so that it is only applied during a web.config transformation upon publishing your site’s release build. The ELMAH article gets into more secure ways such as applying security based upon role authorization.

This insecure ELMAH made me wonder if there were more public facing sites using ELMAH that are not securely hidden from prying eyes. So, I did a google search using the search expression “inurl:elmah.axd Details Form. I was looking for sites configured with Forms Authentication that showed usernames within ELMAH’s Detail page. What I found was not surprising. There were 217,000 results. the results consisted of sites discussing ELMAH while others were the actual details of a site’s error. Below is a sample of an insecure site (details censored).
Error- Elmah.ApplicationException [de002c6c-512b-437e-8a51-0a457d3ff53e]

Noticed I even blurred out the username on this details page! What you can do with this information is run a process to extract all usernames found in the details page and then run a dictionary attack of common passwords.

The takeaway is that ELMAH like most third-party components should be added to the security checklist prior to production deployment. The configuration of ELMAH based upon the ELMAH’s “Secure Error Log Pages” is fairly clear and simple.

Graceful page rendering during page delays

Let’s say you have a page where the presentation dependencies are the javascript code. Usually, all your style tags are placed in the header prior to the remaining elements are rendered. Your javascript is a JQuery plug-in (e.g., some-plugin.js)that takes some element and does some kind of styling to it by applying some CSS classes using its own CSS file(e.g., some-plugin.css).
Continue reading

50 Shades of Hue

I was just reading a post called A Quick ‘n Dirty Color Sequence from an Apple developer named Peter Ammon over at blog called ridiculousfish.com.  It was an interesting way to get distinguishable color sequences for things like bar graphs.  He explains bisecting the regions of the color wheel to determine distinct distant colors.  This doesn’t take into other considerations like colorblindness, print-friendly, and photo-copy-able.  For those color selections, you’re best bet is to check out  Color Brewers for maps.

The code was designed to calculate Nth hues on a color circle (saturation and light disregarded).  I thought it would be interesting to see how to use this for anything besides the example he had on this page. So, I took his code and just adjusted it.
Continue reading