This code is commented and should not require more than is already said.
Now, the essential enhancement I made since the sed era is the removal of all comments and correction of my code to remove all new lines.
I abandoned sed and went to Perl because sed does not support the non-greedy operator, which greatly simplified my work when removing delimited patterns (typically multiline comments).
Getting the full script
It is available on Github. Don’t hesitate to fork and make it better.
Note: the competition
There is none: this is not a tool I would recommend in production environment (for lack of test, for instance).
Why this script is good
It is a quick fix for simple and mostly static websites. It removes potentially sensitive information (many website have their .git repository deployed, containing everything in it, and comments can be a source of leak too, be it only be advertising the technology behind the scenes).
Why this script is bad
I needed something working quickly and without effort. This is it.
You can use it on your server to automatically deploy the latest version of your website. Imagine:
I am a consultant developer. This means I move from client to client and share their time constraints. This includes deadlines, but also work time.
It so happens that some clients have a time clock, like in the old days.
My problem is: while most of my client’s employees can see what the clock stores, I, as an extern, cannot. I do not like to be blind, so each time I am in this situation, like many people I know, I make an Excel sheet where I log my check-ins and -outs.
Sharing my timesheet…
On my latest mission, we were several on the team from the same company. I spent some days without my usual timesheet and when I grew tired, I sent my first basic version, with some conditional formatting, to all members there.
Since they did not seem very interested if I asked whether something standard was available, I did not expect much. But instead, I quickly got some feedback: they asked new features, signalled some bugs, …
The team grew, the requests followed. The possibilities of the timesheet were ever greater, and therefore so was its complexity.
… with the whole world
Finally, using e-mails to track the feedback and release the changelog and user manual became too heavy. I thought of a bug tracker. This led me to create a Github repository. The wiki would come in handy for the user manual too.
Thus the work on version 2, which should make the sheet less specific to our context and more widely usable, began.
When you are a coder, you use a monospaced font. But finding one easy on the eyes is not that easy.
Andreas Larsen did his best to find a solution and he has come with something pretty interesting. In a few keywords, it is clean, sharp, a bit geeky, …
With more words:
It does not have Courier’s serifs.
Every character is easily recognizable. In Java for instance, you need to be able to distinguish without mistake an o from an O or a 0, or an l from a 1. After all, 42l and 421 are not the same thing at all. Riddles are based on this single possible confusion.
The character spacing is smaller than the usual, allowing to see more on your screen when you have long code lines (which I do not recommend though).
It’s Open Source and alive, with a Github project, issues and therefore the chance for the people who use it to make it better over time.
Purely geeky: it comes with funny ligatures. Take a look at the HTML comments in the sample below.
Edit (2015-08-01): The authors have integrated FontAwesome as ligatures into a variant of Monoid called Monoisome. Useful when you develop web projects with FontAwesome.
Tailored to your preferences: you can download it with different line height, character spacing, with or without ligatures, …
This takes the place of Ubuntu Mono as my favorite monospace font for coding. Way to go, Monoid!
Java comes with two similar utilities called StringBuffer and StringBuilder. The latter was introduced in Java 5 and here is what the API doc says about it:
[StringBuilder] provides an API compatible with StringBuffer, but with no guarantee of synchronization. This class is designed for use as a drop-in replacement for StringBuffer in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations.
So, in a nutshell: StringBuilder is a non-synchronized StringBuffer (and is, as a consequence, faster). When does it make sense to use a StringBuffer therefore? The only case I see is when your buffer is a field of a class used by several threads. I must admit I do not see this case.
I often see a StringBuffer created inside a method which will return a String, or passed as a parameter to a method, and my first reflex is to change it for a StringBuilder.
If you did not, well, now you know how to optimize your code regarding to String construction: append all in one time or manage the StringBuilder yourself to avoid creating and releasing many instances, which leads to poor performances.
A year ago, our company tried to put up a team specialized in UX — we dubbed ourselves the UX Avengers, hence the illustration for the post — and wanted its members to trigger some awareness in other developers about the associated issues. This post is translated from the introduction I wrote for the first newsletter we sent.
What is UX?
This notion is sometimes blurry and often confused with UI. UX is the short for User eXperience. According to Wikipedia and the ISO 9241-210 standard, it is “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. The name defines the notion.
Obviously, better the experience is, better are the satisfaction and acceptance of the application.
What should you focus on to make your app’s UX better?
There is a reason UI and UX are so easily confused: the interface is the only thing the user perceives of the application (the look-and-feel). He might be more willing to spend some time on a sober and aesthetically pleasing screen than on a colorful and overloaded screen.
We just spoke about it, though you may have failed to realize it: a screen, as beautiful as it is, cannot be crowded with controls. Your application must be easy to apprehend and understand if it is to capture the users. It is the biggest secret of some well-known companies…
Even if you have the vision, you need the tools to make it concrete, preferably in an elegant way. The arsenal at your disposal is very wide and evolves rapidly. One of the purposes of this newsletter is to allow you to keep in touch with the latest evolutions.
This morning, I arrived at work, booted my machine and launched the core applications I need before even thinking of starting to work: Outlook, so that I can read the e-mail I might have received, Chrome, to see what is new in JIRA, and of course Eclipse which will be used for all development.
Can you guess how long it took to boot and launch only those three? 10 or 15 minutes. Not so much. Just a quarter of an hour lost before even beginning working.
And even once all this was finally up (Eclipse easily took three full minutes), just reading and answering e-mail was a pain. Opening a new tab in Chrome made me wait twenty seconds before I could begin typing in the omnibar, my input for a new message in Outlook had a delay of several seconds, …
It is my (maybe not-so-humble, sorry) opinion that when a developer is faster than his/her machine, there is a problem.
At home, booting1 takes two minutes (half of it being after Windows started). That is already undoubtedly faster than what I have at work, but applications launch in a few seconds too, and they never lag once they are up. Admittedly, I have a killer machine (there was a reason for buying it, even if it is gone now).
But that gives some thinking: lost time is lost money for a company. Which is the most advantageous between losing developer time or buying a efficient machine?