Just today, my company Eleguin, LLC just launched it’s new website design. This not only represents a new look and feel from my old “under construction” site, but it also features a amazing logo designed by my sister, and an outstanding website template from my friend Matt Rogers. Matt did an excellent job of turning my sister’s logo into the exact look and feel in a website that I wanted.
Please, take a look for yourself!
http://eleguin.com
I would enjoy writing a long article about how polishing applications is probably what makes the difference between a decent application and a great application, but I just really wanted to blog about this one feature on Google Reader.
Whenever I read XKCD, there is this nasty bug in firefox which cuts off the title. If you read it in Google Reader though, it appears that google reader shows the full title. I’m pretty sure that Google has made a custom title box for this purpose (maybe it’s not a firefox-exclusive bug). Polish like this is something that you normally don’t see in applications, but which just give a much better experience.
Google Reader:
Main Site:
Nathan has been working pretty hard on releasing version 0.3 of our Hanzi Recognizer program, and finally it has been released, which includes a small change in the GUI.
Over the past few days, word got out about our Hanzi Recognizer program, which has generated upwards of 300 downloads a day, with 1000 total downloads soon to be reached. I’m not quite sure where the popularity all of a sudden sprouted, but we had increased our downloads per day by two orders of magnitude in just a few days, AMAZING!
I have often told people about the bike shed story, which is always something to keep in mind.
I have been reading Code Complete (which I would highly recommend to any software developer) and came across an entry of refactoring. One of the tips for refactoring involves A program contains code that seems like it might be needed someday
. It talks about how designing ahead (and developing ahead) w/o rigorously testing using code that is written is a bad idea for a few different reasons that were listed, among which is that you or someone else will use the methods and only realize that they aren’t implemented, or are poorly implemented. I do agree that scaffolding methods, creating methods w/o testing or really using them at all, is a bad idea, but is sometimes extremely helpful. It can allow a lead developer to outline what he or she is intending to do, and what vision they have for the future of said classes. It allows others to see these right away, but at the cost of having to know just as much about what is or is not implemented.
What I would like to see in an IDE is some sort of software health rating and monitor. Allow you to assign some value to a piece of code, let it be a class, method or property, and from there, you can view the “health” of your code. Imagine scaffolding out a class and being able to give it a “low health” rating. This information can be shared with other developers on the project (even versioned!), so that they may know what parts are well developed, and what parts may not be so well developed. It can allow developers to show “danger area’s” where code may radically change, and “stable” area’s, where code has been tested and is safe to heavily use. This is information that a single developer holds in their head as they are developing, but is hard to convey when other developers get involved. This way, you could be able to see at a glance which code is well tested, and which is not. If you use some piece of untested code, then your code gets the same label.
I believe that with tools like this, it takes an IDE well beyond a single text editor and provides many, many more benefits over just plain vi or emacs. In fact, the extremely poor quality of IDE’s is one topic that I would love to touch on, but is outside the realm of my post today. Maybe someday I will have the time to work on such a feature as a plugin to some unknown IDE that I might bet passionate about someday.