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’ve been meaning to do this for a long time and now the time has come: KeyboardPlaying has a new logo. Which means it will soon have a new website too.
You can find it on Github. Fork if you have any way to make it better (either better looking or just a better construction of the SVG).
Now, this lays the foundations of the future graphical style of the website. The colors were inspired from the Material Design Lite, which I’ll use for the next version of the homepage. It is also flat as I like the current trend to minimalism and flatness. I find it much more soothing than all the fashion of imitating reality, making things 3D like with shadows and so on (though I loved it in that time too, but I was a bit younger; time to be an adult… Or maybe not totally).
No, for the website, just a bit of patience, please.
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!
Remember the Optimus, right? A keyboard with a screen for each key, thus allowing for full customization, changing layout, displaying icons, and so on. But in the end, it never got out. Only ever-delayed.
The concurrence may finally be out: an Australian company answers to the Russian concept with something similar, using e-Ink instead of more traditional screens.
Backlit, customizable, … Just fine…
I wanted an adapter in order to use always the same keyboard (thought of a Das Keyboard or a Code keyboard when they make them as AZERTY), but this could be an alternative solution too.
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.
Keyboard layouts are numerous. Some time ago, friends of mine tried to persuade me to settle for a Dvorak layout. They proposed the BÉPO, though the programmer Dvorak would be more adapted to my professional life.
The idea was attractive. I never settled, though. Why, do you ask? The answer is simple: to be efficient on a keyboard, you need to know its layout by heart and be able to blind-type. This comes naturally after some practice.
However, switching to a keyboard layout has a learning curve. I would not mind if I were able to use the same layout everywhere, but when at work, I must comply with the hardware and rules (“Do not change the configuration of your machine! Get accustomed to your keyboard.”). And sometimes the access restrictions too (“Your rights are not sufficient to configure your clock.”).
In my not-so-long career, I have already had to use several variants of AZERTY and QWERTZ. I sometimes guess type on the Alcibiade‘s laptop, which is an AZERTY configured in international QWERTY. And then I come home and meet yet another variant of AZERTY.
How then to go and try to learn yet another layout?
One time when confronted with a QWERTZ and the explicit order not to change my configuration (as it could mess things up if they ever needed to remote control my machine), I imagined something.
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.