If you still make notes, draw things, etc. then you still need paper and I’ve got a new project you might like. It allows you to create that paper and print it right from your browser. It’s only in an alpha form at the moment (which means not all of the features are finished yet), but you can already put it to good use and print out several kinds of paper in US Letter, US Letter (landscape orientation), US Legal, A4, A4 (landscape orientation), A5 sizes.
Here are a few examples of what it can generate today printed out on a bog standard HP printer using Chrome (which is the easiest to get a great print from on either Mac or Windows).
So, I said it’s just in alpha, here’s what you can expect in a later beta and the final version:
- The ability to do some configuration of the pages. For example, remove the header on the page or change the color of lines from a dark grey to other colors.
- A new Cornell Note-taking layout. Customization of that format will be really nice because you’ll be able to mix graph paper or dot paper into a Cornell layout.
- Double sided pages.
- A to-do list layout.
- Musical staves as another possible thing to put on your pages.
- Printing instructions for Safari and IE.
- A fix for the preview issue in IE 9, 10, and 11.
1. You’re constantly transporting state back and forth between client and server (and often neglecting to do so).
The next time you’re in GMail, notice something interesting about selecting emails. If you check several emails for a mass operation and then realize you’re not altogether sure about one email, so you click to read it, then you come back out to the list, the same emails are still checked. Now do the same test in an app written in any of the classic Java, PHP, Python, etc. frameworks. In those, when the user clicks on the email to view it:
- In all likelihood it was just a link so all of the client-side state (the checked and unchecked checkboxes) is immediately discarded by the browser.
2. It’s slow, slow, and did I mention slow?
- The development cycle itself is slower. I can throw up a temporary API using a variety of tools (or mock it client side using something like $httpBackend) and start work on the UI immediately. As I make each change I just have to refresh the browser to see my change in place. In fact, if I use tools like the Grunt server the browser refresh is automatically triggered when I save a changed file so I can just glance over at it and evaluate the results without leaving my code.
Most server side frameworks involve a compilation step of some type (for example, Java’s JSPs are translated to servlets and then those are compiled to a byte code for the VM). Thus I have a longer wait to view each change I make.
- Users get tired of every thing they click upon meaning another trip to the server. If they just looked at that data a minute ago, it may well be in memory locally so showing it again is free. But if I have to go to the server again to get it re-rendered for re-display, I can get really old fast. I think we can all point to a site where we are frequently frustrated by the slow performance.
- And why is it slow? Well, because it’s not just persisting data and performing queries on it, it’s also combining that data with HTML templates of some flavor to generate full pages and doing so over and over and over again. More work for the server means more servers needed, more time spent on performance tuning, etc.
3. It’s a more complicated programming model.
- For many frameworks, lots of middle tier complexity can leak into the pages, making them way more complicated than HTML and thus much harder for designers (and programmers) to work on. I’ve seen this most often in frameworks where designers are expected not to use standard HTML. Instead they’re supposed to use perfect XML where every tag perfectly matches a closing tag and not a bracket is out of place, or they can’t use the <a>, <form>, <input>, etc. tags, instead each has some replacement which is supposed to be used which typically functions about 70% or so the same as the regular tag.
- I loved this recent quote about JSF, a technology that I rejected at a previous employer because it was very clear that it was designed by committee and not extracted from real projects (like say Ruby on Rails):
4. Debugging is much more complicated.
Something as simple as how some HTML is rendering may require me to setup a debugger on a server on a remote machine because it is being generated from an intermediate file and data on the server.
Mine is not a real software rant, I wrote it tongue-in-cheek after reading one just this week which spun up a bunch of people. Like most of the others, I skipped gracefully past some problems:
- I also skipped over the fact that there are browsers like older versions of IE where the debuggers are very poor and debugging can be just as painful client-side as it is for server-side.
Every framework that has achieved some level of popularity or notoriety has had its share of famous rants (Rails is a Ghetto, Node.js is stupid, and if you use it, so are you!, Why we left AngularJS which has since been renamed to 5 surprisingly painful things about client-side JS). Somebody doesn’t like the language, the framework, the community which goes with it and in frustration they vent. Sometimes they’re right about their complaints and sometimes they’re wrong, often it’s somewhere in between. Just relax and try to read it with an eye to whether the points being made are good ones and ignore the vitriol.
Recently I had to do an interface at work where there were a list of items, each with a separate checkbox, and a separate “all” checkbox which would check or uncheck all of them. At first that doesn’t seem very complicated but it’s an easy interface to mess up because you want the “all” to become checked if the user manually selects every child checkbox. Or conversely, if “all” is checked then you want it to automatically uncheck if even one child is unchecked.
My page had three separate sections with different lists and an all checkbox for each one. I had done my original design with an extra $scope variable representing the “all” checkbox and used a watch, but it still managed to mess up in certain circumstances. It was overly complicated and didn’t work 100% of the time. So my colleague challenged me to build it without the extra $scope variable because he was certain that was the key to getting a flawless solution. Now that I’ve done it, I agree completely.
Here’s a Plnkr with a running copy of the code so you can play with it: http://plnkr.co/IQA9kq
But I just wanted to point out that what makes this work is really this line here. Instead of having the “all” checkbox reflect some variable via ng-model binding, I’ve just hooked it to two functions which handle the action it should perform (no more watch) and another which governs when it does and doesn’t appear checked.
<input type="checkbox" ng-click="allNeedsClicked()" ng-checked="allNeedsMet()" />All needs
In the next day or two I’m going to add this one to my AngularJS example page but I figured if I wrote about it now I would be more likely to get it done.
I wanted to give my existing MacBook (a mid-2009) to my wife because she has had tons of battery issues, performance issues, you name it issues with the commodity Windows 7 Toshiba laptop we cursed her with a few years ago. My Macbook is older but still comes up in a fraction of the time hers does when you open the cover, lasts something like four times as long on a battery charge, and though it’s a slower processor seems to be about as fast for most of her needs.
But I didn’t want to give her a programmer’s laptop with all of my IDEs, extra browsers, compilers, databases, etc. installed on it. I wanted it to be a just like new experience. So I removed the stickers, scrubbed the aluminum exterior (though I couldn’t do much about a few small scratches on the bottom of it, the top still looks pretty new); and cleaned the screen, keyboard, and trackpad thoroughly. But when it came to completely formatting the hard drive and installing a brand new copy of OS X Mavericks it seemed like it was going to be a lot harder. For example, this article on doing a clean install was pretty typical: http://mashable.com/2013/10/23/clean-install-os-x-mavericks/
Whoof! That’s a lot of work to do something that should be pretty easy. It turns out, it can be:
- First make sure you can use the Command+R when you boot your MacBook to go to the recovery screen.
- If that worked, start up your Mac again normally and install Mavericks on it. It’s still your old stuff on the machine though, just with a new OS on top of it.
- Then reboot and use Command+R and go into the recovery screen.
- Use the Disk Utility in the recovery screen to format the hard drive and use the Reinstall OS (again a recovery screen tool). After that you’ll have a fresh clean machine with OS X Mavericks on it.
It might not be the fastest way to do it because you did two installs of Mavericks on the same machine, but it was much easier than downloading special tools and creating USB boot keys.
I have a strange little project I’ve been working on over the last few weeks. It’s an example app I wrote using Node.js which is capable of self-upgrading itself to new versions. Thus you could use it as the basis of a cross-platform application with a browser based UI like SABnzbd+, the Plex Media Server, Couch Potato, and Sick Beard. All of which work on different operating systems (Mac OS X, Windows, and Linux) and which offer the same UI across all of them. So, this isn’t really intended for use on servers as much as it is intended for use on desktop machines so you can build apps using Node.js and whatever front-end technologies you happen to fancy (my particular flavor is AngularJS, though there is none in the example application).
I got it to where it works well on Mac OS X so I thought I’d write about it and maybe someone else would find it interesting enough to see if they could add a Windows batch file to it, maybe test it on Linux, or see if it suits a project they have been wanting to build. It’s called “selfhelp” and it’s available over on Github:
- Don’t try to sequence operations from the front-end. I once answered a question on Stack Overflow where the asker wanted to know about how to sequence a seven step process for paying for something. I answered it once telling how to do it and then again to say never to do that. You should not have your front-end be the conductor and the back-end be the orchestra. If you do, you will be sorry because eventually someone will lose their web connection, close their laptop, or just shut down their browser in the middle of your carefully choreographed sequence. Instead, always try to make API calls from front to back that provide complete units of work, complete transactions with all the information needed for multi-step operations so you won’t end up with only part of an operation completing.
- Please, don’t be afraid to reject some ancient browsers. There’s good code out there to help you do it and make it look nice, but ultimately you’re doing yourself, your users, and everybody else a service if you refuse service for IE 6/7/8 and maybe more than that depending upon your needs.