I’ve finally gotten around to creating a favicon for my site. I’ve always found this to be a finicky process, mostly because I’m the farthest thing from a graphic artist around. Since this is something I have tried to do a few times, never quite getting it right till now, and I’ll likely not try to do this again for years, I figured recording the process here would be good for future reference.

First, create the base image to be used for the icon. I found that doing this in a vector graphics program like the freely available Inkscape made life quite a bit easier. The trick is to create a square page and build your image filling that square. It does not matter how big the page is while you build it because you can specify the image size at export time, and Inkscape will take care of clean aliasing of lines at that time. Just don’t get too detailed because the smallest icon size is only 16px by 16px, which doesn’t give a lot of resolution to work with.

I created this SVG image as the base for all subsequent files:

Yes it is small, but this is only because I sized the page to be 16x16 px, forgetting that the size doesn’t really matter when used as just a base image.

After creating this base image, I then used it to export PNG files of various sizes: 16x16, 24x24, 32x32, 64x64, 110x110 and 114x114. The 16, 24, 32 and 64 are only used for the favicon.ico, but the other two larger formats are used to create facebook.png and apple-touch-icon-precomposed.png respectively. Exporting these files using Inkscape involves choosing Export Bitmap... and filling out the appropriate fields in this dialog:

And the resulting images:

favicon - 16x16 px:

favicon - 24x24 px:

favicon - 32x32 px:

favicon - 64x64 px:

facebook.png - 110x110 px:

apple-touch-icon-precomposed.png - 114x114px:

The facebook and apple icons can be used as-is, but an additional step is needed to turn the separate favicon images into a single *.ico image. This is where Gimp comes into play. With Gimp, open the largest 64x64px image. Then choose the menu option to Open As Layers... to open the other three images of different resolutions. This will pull all of your favicon images into the same Gimp layered image.

Finally, you can export the layers to a single Icon file containing all resolutions. Choose the Export As... menu option and in the resulting dialog, enter the file name favicon.ico and choose Microsoft Windows icon (*.ico)

On clicking the Export button, you are presented with a dialog for setting options on all available formats.

I did try using a smaller palette size to reduce the resulting file size, but I needed to keep the 8-bit alpha channel. Otherwise, the circle is rendered with a jagged boarder. If it weren’t for that, I could drastically reduce the palette size, making the icon ¹⁄₄ of its current size.

Some reference I used while working on this:

• http://en.wikipedia.org/wiki/Favicon
• http://demosthenes.info/blog/467/Creating-Multi-Resolution-Favicons-For-Web-Pages-With-GIMP
• http://realfavicongenerator.net/faq#.VKGwtAAA

I’m looking into Scalate as the templating engine for my web site rewrite, and I’m doing this for several reasons.

• It natively supports Scala
• I like the Jade syntax for DRY (Don’t Repeat Yourself) HTML page creation
• Pages are generally compiled into bytecode for high performance execution
• It has the ability to perform CSS selector driven DOM manipulation similar to what a browser does, only on the server side

While playing around with this last night, I did encounter one detail I’m not too happy about: template inheritance. It would appear that inheritance in Scalate does not work as advertised in the Jade syntax spec. The block and extends key words look to be treated like regular tag generaters vs. keywords that serve a special compositional purpose. I may be missing something, but the more I think about it, the more it seems reasonable this is the case.

Scalate is designed as a templating engine that supports many different syntaxes. I imagine wiring all these different syntaxes together within the render pipeline of the template engine would yield a half baked and quirky solution. Instead, composition of pages can be accomplished via a more dependency injection approach. Instead of composing inheritance trees in the templating layer, each template should provide places where Scala variables are output into the page. The Scala variable can be, for example, simple text for output or another templated component. Composition is accomplished from the outside in using Scala code.

The trick to making this a successful and pleasurable solution is figuring out how to make this compositional approach concise and simple. The last thing I want to do is have some involved declaritive structure for every page.

UPDATE: I have confirmed Scalate’s Jade template system does not support block and extends, though not for the reason I originally thought. It just hasn’t been implemented yet. See [https://groups.google.com/forum/?fromgroups=#!topic/scalate/A-NOeZazjIQ]

The goal of the new design is to support several reusable components with the intent of keeping them light weight and modular. Some desirable features include:

1. A JavaScript based navigation widget

This could also include common header, footer, left-hand navigation, etc. The idea is to use the browser to apply common UI components into the page. This appeals to me as a software designer because it enables one solution to be used consistently across all application components within a site having nontrivial architecture, regardless of the technology or templating mechanism used. As long as the UI is rendered in a browser and each application can provide the same hooks (possibly just insert at start or end of page) then this will cut down on re-implementation of the same functionality leading to inconsistencies and annoying maintenance issues.

At first, the design would focus on a simple and static navigational structure, possibly leaving a second tier navigation for each participating application to manage on its own (probably won’t have that complicated of a site myself). The more static the JavaScript, the better the user experience from a performance perspective.

Eventually, the navigation will also be concerned with customized navigation elements. Custom navigation assumes a user has been authorized or has selectively chosen to view a subset of the overall site. This user experience feature becomes more important if you have private areas of your site or the site becomes so large, the navigation cannot comfortably fit within a single view. I personally had a revolutionary thought a while back (tunnel vision, I suppose) when I realized a Java Servelet (or any other dynamic web code) is just as capable of rendering JavaScript dynamically as it is rendering HTML.

Note that custom navigation requires some concept of identity for the current user. Identity will not be within scope of this widget, but will need to consume that identity information, which leads me to the next component.

2. Identity Service

Identity management is a nontrivial issue to tackle when dealing with distributed applications. There have been many attempts at solving the problems in this domain, and even the simplest solutions are not as simple as one would hope, particularly when implementing both the identity authority and consumers for a single site. Since my goal is to aggregate many technologies under one web experience, I will need to have them relay identity seamlessly for Single Sign On, as well as share basic information between them… if identity is needed. One technical detail in my favor is I intend to run much of this under a single domain, which makes cookies a viable option for relaying some critical details (e.g. a cross-application session cookie containing a token that can be used to look up identity and session status info from a centralized RESTful web service). Of course, since there are already standards surrounding identity distribution, it would also be nice to leverage some existing libraries for supporting this. Since I’ve already had experience with OpenID, perhaps a light-weight OpenID Connect server would be a good path forward, though a bigger investment in time and brain power that may not be feasible in the near future.

This feature is of particular interest to me because I’ve been working in this space professionally for the past few years. I have some ideas on how to simplify this given this specific use case, and have a desire to explore the use of Akka’s actors to support this. Ideally, the server would be extremely easy to start up and configure, and is designed out of the box to support high availability if not global distribution; however, I’ve not been able to get a global distribution under my belt yet. The biggest threat to this not happening is I will not be implementing and/or using this in my day job. This may also turn out to be a blessing, as it will force the implementation to be simple due to time constraints and a “just get it done” mentality. Using a terse language like Scala may help as well, but running in the JVM does somewhat ding my goals for minimal resource usage. Right now, I am taking the Hudson/Jenkens deployment model as inspiration, and I’m hoping that if I can implement this once, integration with other systems should be low hanging fruit.

3. A JavaScript based commenting widget

The design principal is pretty much the same as the navigational widget, but this is intended for distributing a comments & collaboration system that is centrally managed. The thought for this widget came to mind because I intend to serve most of my content in a static format going forward rather than running an application server to serve up the same stuff over and over. This has benefits from a resource usage perspective, as well as an operational support perspective. The fewer moving parts, the more reliable and less critical the issues.

The django server I’ve been running in “production” (with extremely low traffic) has not given me much grief at all, and it already has a pretty good set of administrative functions for comments, so maybe I’ll build this feature on top of what I already have running.

One potential wrench in the works I’ll have to work around is cross site JavaScripting support. Keeping all applications running as application contexts under a common domain will make this a non-issue, but I don’t want to design myself into a corner that prevents sites with differing domains from using the commenting tool. This may require a kind of server-side proxy that lives on the different domain, but relays data via a server to server communication… food for thought.

The concept of identity also plays a part in posting comments, though it isn’t absolutely critical. The initial implementation may function anonymously but allowing the user to provide a name via a form field. Then as identity gets rolled out, a signed in user would automatically have their name populated and fewer limitations would be applied on what the user can post.

I’ve recently learned that I have a bunch of options available to me to play with my web site… and so much more. My interests in keeping my blog up are more for playing with web technology than anything else. I had learned quite a lot in building it, which turned out to be highly beneficial when taking on new responsibilities at my work. A few years later, I am now ready to grow a bit more. Given that my budget is modest for, my goals will be to pursue some of my nontrivial interests (time permitting as usual) in as robust and minimalistic as I can manage.

1. My shared hosting provider Webfaction has generously upped the resources provided to their base shared hosting offering such that there is now a LOT of memory made available to run applications. Now I can entertain running things like a JVM if I so desire. I will not complain for getting more for my money!

2. I have had to change my ISP provider from DSL to cable modem due to insufficient bandwidth. I didn’t get remotely near the advertised bandwidth from the DSL provider because my residence is too far away from the switch. So, for a little more money, I now have a 13x faster network connection and as an added bonus, am able to connect to my machine from the outside world. Maybe I’ll be able to set up some distributed computing between my home machine and my shared hosting provider. Now, if only I can find a reason to implement such a thing…

3. I’ve learned of Scalate which is capable of generating web sites as static HTML. That is, you build your predominantly read-only site as you would for a dynamic one, and instead of deploying a runtime, you “compile” your sources into static content to be delivered cheaply. I’ve been looking for quite some time for a good solution for managing my personal notes. Tomboy isn’t as portable as I’d like, a wiki requires a network connection, I need to support both Windows and Linux, and would like good version management of my changes for historical purposes. Writing my notes in Markdown format and checking into a distributed VCS (Mercurial or Git) for distribution, versioning, and maybe even deployment.

4. I now have some more experience with integrating web assets served by separate technologies into a unified site through some browser magic. This should allow different solutions to run at the same time instead of pulling/porting everything under a single technology as I have done in the past.

What is wrong with Django?

In short, there is absolutely NOTHING wrong with Django. In fact, I still find it to be an extremely flexible, powerful and not to difficult to grok framework. I still like it quite a bit, though I’ve not been able to keep up with the latest developments. I find that the way my site is currently set up, I have to intentionally spend time to add anything to the site, which I never do. I would prefer turning the site into a tool I can use on a daily basis for tracking things I find interesting. Then, maybe I’ll actually keep it up to date, and make use of the site I’m paying good money to play with. I’ve not fully committed myself to moving my blog off of Django just yet. Doing so would mean abandoning the comments feature, though admittedly I don’t get many comments beyond those of an undesirable nature. As a result, I’ve taken to disabling comments to cut down on moderator notifications and save database space.

Conclusion

So, my plan going forward is to pursue a more heterogeneous collection of components that are selected and/or designed to work together. I trend toward low maintenance solutions that either satisfy a need or simply tickle my fancy. After all, this is my playground for exploration and skill development.