I started to look into it and noticed that both results were returned when searching for the part of the word leading up to the very non-English letter of “ä”, but once that letter was added, the second result disappeared.

The horror slowly began to dawn on me: I was dealing with a character encoding issue.

Time to dig in. I launched the Rails console, fetched the strings and started to cut into the them.

"Akilleshäl" == "Akilleshäl" returned false. Some more cutting. "ä" == "ä" returned false.

Since I was pretty sure this was encoding related, I used the String#bytes method on both characters.

"ä".bytes => [195, 164] "ä".bytes => [97, 204, 136]

As the saying goes:

If it looks like a duck, swims like a duck, and quacks like a duck, then it is either a duck or a unicode equivalent animal.

Yes, Unicode equivalence is a thing. The byte sequences above will render identical characters, even though they mean slightly different things. In UTF-8, the bytes 195 and 164 are interpreted as “Latin Small Letter A with Diaeresis”, or “ä”.

The other byte sequence means “Latin Small Letter A” (97) followed by “Combining Diaeresis)” (204+136). More simply put, take the letter “a” and slap two dots on top of it. Or “ä”.

Great, now I understand why it doesn’t work, but I still have no idea what to do about it. I tried to string words together to get Google to lead me to a solution - only marginally more evolved than a monkey in the infinite monkey theorem - until I finally stumbled on the magic word: normalization.

As it turns out, Unicode normalization is standardized by the Unicode Consortium. There are a bunch of different algorithms, which I did not have the mental energy to read, but the important point is that they will turn both byte sequences above into the same byte sequence.

Luckily, Ruby introduced String#unicode_normalize in version 2.2. Let’s take it for a spin!

[97, 204, 136].pack("c*").force_encoding("UTF-8").unicode_normalize.bytes => [195, 164]

Boom!

Let’s just quickly go through what happened here. The 3-byte sequence is packed into a string, then Ruby is told to interpret this as UTF-8 before applying the default Unicode normalization algorithm. Finally, the byte sequence is returned, which now matches “Latin Small Letter A with Diaeresis”. Or “ä”.

It was now possible fix the specific issue that got this snowball rolling. I was interested in finding all records where the name was not normalized and normalize it, which looked something like this:

Model.pluck(:id, :name).reject { _1.unicode_normalized? }.each { |id, name| Model.find(id).update(name: name.unicode_normalize) }

The reason for plucking id and name first was to not crash the Rails console running on Heroku due to excessive memory use (a full ActiveRecord object uses more memory than just a number and a string). If you have even more data and you’re running PostgreSQL 13, a more efficient approach (I assume) is to use the built-in IS NORMALIZED function and only query the affected records from the database.

To ensure we avoid this problem down the line, we are also applying the normalization on relevant fields for all future records in our ActiveRecord models by extending the String type used by the attributes API - but that deserves a blog post of its own.

1. Search for credentials to the server where the only copy of my blog existed. Found them well hidden in an old 1Password vault.

2. Clone the Git repo of my blog from that server.

3. Write a blog post. This did not take as long as the rest of these steps.

4. Find out how to use Octopress 2. To be clear, that is an older version of a static site generator that seems to have been unmaintained for quite a few years now.

5. Remember my weird af deployment method. How to deploy, you wonder? From my laptop I commit the newly generated site, push to a remote repository on the server, SSH into the folder from which nginx serves the files (which is on the same server) and git pull. Genius.

6. By this point, the post was actually published, but I realized that the blog wasn’t served via HTTPS, which just feels unacceptable in the day and age of Let’s Encrypt.

7. As I was going to setup Let’s Encrypt, I also realized that the server was running Ubuntu 14.04.5, which was released mid-2016.

   I’m not sure if I should give myself credit for telling my wife somewhere around this step that I would regret doing this.

8. Before upgrading I checked if there were any backups of the droplet on Digital Ocean. The answer was no. I enabled backups, but the first backup would not run until next morning, so they would not cover me right now.

9. Instead I shut down the instance and took a snapshot which I could recover from later, if necessary.

10. Upgrade server from Ubuntu 14 to 16 and then straight on to 18. What could go wrong?

11. Something went wrong. The upgrade broke an old site running on CodeIgniter 2 and PHP 5, which I had no intention of spending much – or preferably any – time maintaining. The problem was that only PHP 7 was installed now, which didn’t play well with the site.

12. I found an alternative package repository from which I could install PHP 5.6.

13. The version of CodeIgniter the site was using had an issue with PHP 5.6, so I monkey-patched the framework core files to fix the error. ¯\_(ツ)_\/¯

14. No errors anymore, but the site was only displaying a blank page. After some searching it turned out to be a missing PHP 5 mysql package.

15. I was finally ready to set up Let’s Encrypt, which was already running for the site I had just broken. I upgraded LE and made sure everything was still working for both the new setup and the old.

16. Profit?

This is the kind of moment that reminds me of what working in tech is all about: perseverance and Google.

In unrelated news, I’m taking suggestions on which static site generator to use moving forward.

New is always better used to be less of a joke. Perhaps it’s because there are fewer surprises these days. That third camera in your iPhone? It’s obviously not as exciting as when your phone got its first camera. Or perhaps it’s because I’m older. Jaded, even?

I think React was the last time I felt genuinely excited about a new technology. It was late 2013 and React was only a few months old. There was no Redux, only vague mentions of something called Flux and top-down data flow. I enjoyed exploring the ideas and discussions that took place, both in the React community but also in the JavaScript community as a whole.

As it happens, six years later, I still use React. It’s less exciting these days. I try to keep tabs on what’s happening in the community and the ideas that are being explored. Not because I’m waiting to jump on The Next Big Thing, but simply because I want understand how future developments will affect what we’re doing today.

The tech stack I’m currently working with, besides React and JS, is Ruby on Rails running on Heroku with a Postgres database and a Redis store. There’s no TypeScript. No Cassandra. No Kubernetes. No Go.

By all means, it’s not PHP 3 and Mootools or, God forbid, Java. (That last part may or may not have been a joke.) But it’s not really… shiny.

You know what it is, though? It’s dependable. It’s well documented. It’s easy to use.

As someone who once spent two weeks debugging a concurrency issue with a custom built Java SAML2 authentication module in a custom built Java HTTP server, I’ve come to appreciate dependability, good documentation and ease of use. (Also, I realize why I may or may not have joked about Java.)

I’m gonna steal a quote from my friend @bjoreman, but I figure it’s okay, since he stole it from Andy Hunt. Just let this mother of dragons sink in, and enjoy the rest of your day:

Boring has its place.

My feed is almost exclusively filled with very clever people writing about programming languages, software design and new technology. There are so many cool ideas and shiny new things that there is no chance of me keeping up. I’m lagging behind. Shit! I should really learn Go now, so I’m ready when all other server-side languages are phased out. Oh, is Go old? Damn it, I’m too late! Elixir is still hot, right? Okay, I can learn Elixir, looks easy enough. I just have to understand GraphQL and how to integrate that into an existing React application first. Though, perhaps Meteor would be a good fit? Got to look into that first. Oh, here’s a post on Medium about how to stay productive! If I read that, perhaps I will manage to do everything else.

Twitter is stressing me out. I’m entirely sure that there is some cognitive bias that makes me feel this way, so add that to the list of things that I need to read up on. With all the developer evangelists, core contributors and successful start-up founders keeping my feed constantly updated, this also means that keeping up with the state of things has become more and more about consumption.

Almost all of my time spent on devices is spent consuming things. Blog posts, tweets, videos, games, music. The lack of me producing something by myself adds another layer of stress, but how can I write something insightful about Javascript if I don’t fully understand the inner workings of V8, Chakra and Spidermonkey? The logic goes that to produce, I need to consume, but there is not enough time to consume which means there is never enough time to produce.

Taking a short break from consuming Twitter is an experiment. A few years back I actually wrote about the joy of not being connected for a few days. It turns out, I fell back in the same pattern pretty quickly. This time, I will uninstall Tweetbot from my phone, tablet and computer for a fortnight. Why a fortnight you ask? Because it sounds Shakespearian, that’s why.

All other social networks will remain. I currently spend around five minutes a day on Instagram and along the lines of thirty minutes a week on Facebook, so they are not really time sinks at the moment. I’m curious to see if I will begin to fill the void by reading status updates by my high school classmates, or if this in any way helps with the admittedly small problems described above. Perhaps I’ll take up App.net or Ello. Just kidding.

See you in two weeks, Twitter. Probably.

At the Automattic (most notably the company behind Wordpress.com) conference booth I was able to get my hands on a book called “The Year Without Pants: Wordpress.com and the Future of Work” by Scott Berkun. I covers the author’s experience of working as a team lead at Automattic for about two years, and since that sounds fairly boring, I think we understand the reason for the click-baity title.

So, seriously, about the title. It is a reference to the fact that Automattic is a fully distributed company, and as such one could very well be in a meeting with any number of colleagues whilst wearing nothing but tighty-whities. That’s a damn good title. I’m assuming the subtitle was added later when someone realized that only “The Year Without Pants” sounds like a movie starring Steve Carell and/or Jason Segel.

The reason I wanted to read this book was my interest in the postmodern view of management. I say postmodern both because it makes me sound smart, but also because it really is a reaction against the the typical modern 20^th century way of managing employees:

• fixed hours
• fixed location
• money as motivation
• management hierarchies

I’m interested in this because I think the old way has gotten a lot of things wrong, especially when it comes to jobs with at least an ounce of creativity involved. At the same time, I always feel skeptical whenever someone starts talking about flat organizations and no management.

Scott Berkun was hired at a time when Automattic was growing rapidly. Previously the founder and CEO of the company, Matt Mullenweg (who is also one of the creators of Wordpress), could have complete insight to everything that was going on while letting people work on pretty much whatever they felt like. This is sometimes referred to as “no management”, a term I know has also previously been used at for example GitHub. This is obviously not true, since any company that lacks management won’t be a company for very long, so let’s instead call it a “light organization”. As more people were hired, however, the organization needed to gain some weight.

This is the very core of the book. How can a light organization grow without causing chaos? Which features of the old way of doing business are needed, and which can be ignored? And how do you introduce such practices without negatively impacting the company culture?

For example, the problem of managing a growing number of employees was dealt with by introducing a hierarchy. As far as I can remember, that word is not actually used in the book, but the employees where divided into small teams, where every team had a team lead. Berkun, who had a lot of experience as a manager at Microsoft, was hired as one of those leads.

That being said, the hierarchy at Automattic was a lot less rigid than the ones you will typically find at major (or minor for that matter) companies. People were still distributed and had access to most of what happened in all the other teams, not only the one they currently belonged to, but they were also expected to work on specific parts of the system.

At times the book reads a little bit like a sales pitch, but I do think that the author manages to point out the problems that will inevitably appear when working with a postmodern style of management. One such example is how when people get to choose which task to work on, they usually go with the low hanging fruit, the fruit which seems tastiest, or the fruit that just exploded on millions of users. Less often will people choose a tough, boring task even though it would greatly improve the experience of the end user. Apologies for not bringing the analogy all the way home.

All in all, “The Year Without Pants: Wordpress.com and the Future of Work” is definitely worth your time. It’s easy to read and it’s interesting to follow how Scott Berkun tries to apply his experience in management while simultaneously adapting to the culture at Automattic.

The menu worked fine in Chrome and Safari, but when I tried it out in Firefox there was an issue. When right-clicking, the menu would appear but when the mouse button was released, the menu disappeared again.

Technically, the library works like this. When a right-click menu is registered, an event listener is added to the specified DOM element for the contextmenu event. The listener shows the menu and adds a new event listener to the document which is responsible for closing the menu whenever the user clicks outside the menu’s boundaries.

The contextmenu event is a non-standard event, but it is implemented by all the major browsers. Firefox, Chrome and Safari all consider this to be a mouse event, though in the draft of HTML 5.1 the contextmenu event is not necessarily considered to be a mouse event.

As I said, Firefox would open the menu and quickly close it again, and given the above description I started looking into which events were fired. I wrote a small test page which registered listeners for mousedown, mouseup, click and contextmenu on a div and the document, in both the capture and bubble phase. This is the event order in Chrome:

1. mousedown (capture) on document
2. mousedown (capture) on DIV
3. mousedown (bubble) on DIV
4. mousedown (bubble) on document
5. contextmenu (capture) on document
6. contextmenu (capture) on DIV
7. contextmenu (bubble) on DIV
8. contextmenu (bubble) on document
9. mouseup (capture) on document
10. mouseup (capture) on DIV
11. mouseup (bubble) on DIV
12. mouseup (bubble) on document

Safari acts the same for the first two events, but never fires a mouseup event. And this is what happens in Firefox:

1. mousedown (capture) on document
2. mousedown (capture) on DIV
3. mousedown (bubble) on DIV
4. mousedown (bubble) on document
5. contextmenu (capture) on document
6. contextmenu (capture) on DIV
7. contextmenu (bubble) on DIV
8. contextmenu (bubble) on document
9. mouseup (capture) on document
10. mouseup (capture) on DIV
11. mouseup (bubble) on DIV
12. mouseup (bubble) on document
13. click (capture) on document
14. click (bubble) on document

As you can see, there is a slight difference between Chrome and Firefox. Logically, I think it is reasonable to do as Firefox does and fire a click event. But look a little closer on the click event. It only appears two times, both on the document. In other words, it never hits the div on which the click originated, though the target property correctly references the div.

After some googling, I managed to find a bug report on Bugzilla for this issue which was marked as invalid without any real reason other than “there is no specification”. I’ve added a comment on the issue with the hope of getting an explanation, but until then I wanted to share this in case other people run into the same problem.

The problem, as I see it, is that there is somewhat of a context switch. You leave the application and are sent to Dialog Land. Admittedly, you seldom stay long in Dialog Land, but you are broken out of your current flow. It can be argued that this is the point, since this break of context means the user is forced to consider if they really do want the go through with the action. We should of course do this in the case of irreversible actions, but is a modal dialog really the only way?

My idea was to keep the user in the same place visually by simply replacing the action button with a confirmation button on click, requiring an additional click to go through with the action.

There are two problems with this. First of all, the user might not even notice that something has changed. The buttons still have the same colors and are about the same size, so there is not enough of a visual cue that another action is required. Secondly, the immediate switch means that an involuntary double click will lead to a confirmation.

The second point is easily solved by adding a delay before the action can actually be confirmed. A few hundred milliseconds is enough for that. We can however use this time to also visually indicate that something has happened by changing the text and indicating that the button is inactive. To make sure the user has time to realize this, the delay needs to be at the very least half a second, and I personally found around one second to be a decent trade-off between usability and user safety.

The remaining problem as I see it is that a user who is 100% sure that they want to perform this action is forced to wait. Especially if they are performing this action repeatedly, it will get annoying pretty quickly.

One idea, which I haven’t implemented yet, is allowing the user to bypass the confirmation step by holding Command/Control while clicking the button. The risk however is that this forms a behavior with the users where they always perform actions this way, effectively removing the safety net.

As always, I’d love some input. Is this over-engineering for a problem which already has a solid and accepted UI pattern? Is it reasonable to allow a user to bypass confirmation of dangerous actions? Lets hear it in the comments.

EDIT: I posted a Gist containing a sample implementation of this confirmation button in Javascript and React.

Both the actual need and the user’s perception of that need will change as programs are built, tested and used.

The most common realization of these changing needs is probably the feature creep. A person who has two problems, A and B, and get access to a system that solves A would obviously like it to also handle B. Lets call this the “one system fallacy”.

This is a belief that there should be one system to rule them all, so to speak, though this rarely leads to a good end result. What one usually would like, however, is multiple applications that complement and integrate with each other. For example, I’m sure someone, sometime thought that adding a word processor to Gmail would be great. It wouldn’t have been. A much smarter move was building a separate application for the word processor, but which shares the same login as the one I use for my e-mail.

Another problem is that often times people are not really stating their problems, but rather their ideas of solutions to problems. In one of my courses at Chalmers I heard an anecdote about the development of a new American fighter jet (I’m paraphrasing, but if anyone knows the source, please share). The company that got the order received a requirement stating that the plane should have a top speed of mach 5. This wasn’t feasible so the team tried to locate the source of the requirement. After much searching, it turns out it came from the pilots. When asked why, they said they needed to be able to outrun missiles fired from a MiG.

In other words, the problem was not that the plane was too slow, the problem was that they would get shot down by the enemy. A much more practical solution was to improve the electronic countermeasures. In the sphere of web development, the requirements we get can be something along the lines of changing the color of the links or adding file uploads to our comments. Either way, it is important to understand what the problem is.

Once you understand the problem, you need to understand how critical a solution is. This is sometimes obvious. Implementing a Tetris easter egg would probably fall on the opposite side of the scale from a bug causing the system to crash whenever a user logs on. Other times it is less clear, but I’ve found that important things tend to pop up multiple times from multiple sources. If you’re unsure, give it a lower priority and wait.

When communicating your the plan regarding the suggestion to the user: underpromise and overdeliver. Not everyone agrees with this tactic, but dealing with changing requirements means you are unable to promise much even for seemingly simple suggestions. Once you do implement something, let them know and they’ll be grateful (and most likely be ready with a few more suggestions).

I’ve heard lists are a great way to get readers, though I couldn’t bring myself to use that selling point in the title. Instead, lets half-ass it and summarize the steps that should be taken when receiving a suggestion.

1. Listen. Don’t be an asshole, hear your user out.

2. Identify the real problem. At first the suggestion might not make sense, but it may very well lead to an important change or addition once you grasp the underlying issue.

3. Prioritize. I rarely say no to suggestions, but I’m also careful to point out when something is technically challenging or might be out of scope. Underpromise, overdeliver.

Have I missed something? Am I wrong? What are your experiences with dealing with changing requirements in a light-weight development setting?

The book was originally published in 1975 and received an update for its 20th anniversary, which included a few extra chapters. The author, Fred Brooks, received a Turing Award for his efforts in the field of computing in 1999.

Okay, enough with the backstory. As can be expected from a forty year old book, anachronisms are plentiful. This was a time were the available amount of memory was measured in bytes without any prefix, documentation was updated, printed and physically distributed and, perhaps most importantly, computer-time was a scarce resource.

The problem with the book is its age, by which I don’t mean these kinds of anachronisms. Our field has thankfully moved forward somewhat in the last 40 years, even though Bret Victor might not agree. Instead, the main problem is that during this period in time (60s and 70s), the reigning development process was what we refer to as waterfall.

I should be fair and point out that this very problem is highlighted by Brooks in the last chapter, which was added in 1995 and contains his own reflections on what had changed in the last 20 years. The fact still remains though that large portions of the book deal with typical waterfall model problems. The most prominent such problem is perhaps how to better create system specifications that are complete and correct, a task which for most real systems is unfeasible.

There are however good points that are valid even today. For example, when defining milestones for a project, they “must be concrete specific, measurable events defined with knife-edge sharpness” so that team members have no way of fooling themselves that something is “basically” finished.

The author is also obviously aware of the problems with changing requirements, stating that “both the actual need and the user’s perception of that need will change as programs are built, tested and used”.

The book is interesting, but assuming you are working in a fairly modern organization (by which I mean you don’t strictly follow the waterfall model) I don’t believe it will push you or your manager to enlightenment. The best part of the book was actually the new chapter discussing the differences in the field between 1975 and 1995, so if you want to read it I would recommend you do so with the goal of better understanding the earlier days of software engineering, rather than learning how to structure the perfect organization.

Finally, I do not wish to imply that dealing with changing requirements is a solved problem. Agile methodologies have given us better tools, but there is a reason that we are not all using the same process. It seems Fred Brooks was correct when writing that “structuring an organization for change is much harder than designing a system for change”.

As I read the the text, Dustin really won me over. However, as I’ve been working on a side project lately, using your just didn’t feel right. I tried to think about the reason for this, and I believe I came to a conclusion.

I think the basic argument of whether or not the interface is communicating with us as a seperate entity is correct. The problem is that sometimes interfaces do both. In my opinion, using the word my feels like it refers to something I have created, and your refers to something the system provides for me. As an example, consider the website of a news paper. There are two types of users, readers and writers, who each have access to a different interface because their purpose for entering the site is different (consuming and producing, respectively). Now consider the navigation item “My articles”. In which interface would this feel most appropriate? For the consumer it may refer to a page with articles that the system believes I would enjoy (though I agree the title could have been a bit more clear on that), and the producer could perhaps get a list of articles he or she has written.

This is highly unscientific, but my seems to have a stronger sense of ownership than your. If I see “Your messages” on a site, I think of communication and messages other people have sent me, whereas “My messages” more sounds like messages I have written. Put differently, your sounds like something for me to consume and my something I have produced.

This is where it becomes a little bit complicated though, because if the choice of wording is linked to consuming vs. producing, there will often be a need for both words on a site. This would however be an issue all of its own, since I believe most people would find it strange to have “Your messages” next to “My articles”.

A third, and of course valid, option would be to just drop the possessive pronoun altogether, but this could cause the interface to lose some of its personality. In the end, I guess it comes down to simply making a choice and sticking with it, but if anyone has a quantifiable way of deciding, feel free to share in the comments.

Since the DNS-320 has two slots, I bought a Western Digital Red 3TB SATA III, which should fill our needs at home for some time. One of the nice things with getting a NAS was that adding a disk should be pretty much plug-and-play. Thus I inserted the new drive, entered the web interface for the NAS and begun formatting. Initialization went fast, but then progress halted at 0% when formatting. I aborted and retried, but to no avail.

After a while I finally manged to find a solution. I shut down the NAS, removed the original disk which was in the left slot, inserted the new 3 TB disk in that slot and booted up. Formatting now magically started working.

Both disks were now available, but there was a new problem. The DNS-320 runs Linux and by using a little hack known as fun_plug, we can gain access to the OS and install additional software on the device, such as a web server or a torrent client. This hack was installed on the original disk, but even though both disks were identified, fun_plug wouldn’t start.

As I searched for a solution on this problem, I found a wiki for DNS-323 where the same problem was described. It turns out that fun_plug needs to be on the right-most disk in order to start up, so I had to make sure the original disk which had it installed resided in the right slot.

Mission accomplished.

How about performance then? When Chrome began to overtake Firefox, performance was one of they key reasons that made people switch. Its Javascript engine was much faster and the browser consumed less memory. Since then things have evened out. Chrome started a speed war which was great for users, since it forced the other major browsers to follow suit. The same has been true for memory and start-up times, though perhaps more quitely. Lifehacker’s latest browser test (June 12, 2012) revealed that Chrome is still kicking ass on the JS side, where as Firefox leads the way in memory and tab-loding.

As you see, I consider Firefox and Chrome to be more or less equal when it comes down to features and performance (and I could very well add Opera and Safari to the list). That brings me to the idea behind the browser, what drives the development.

I believe the Internet should be free and open, and because of that I prefer to support a browser whose only interest is promoting a free and open web. Can we so easily separate the tool from the idea? Can we really trust that commercial interests in the browser market will not spill over and influence the web? My answer would be no, because it is only reasonable that Google’s bottom line is an important factor in the future development of Chrome.

That is why I choose Firefox.

The size of the target group has admittedly decreased somewhat since the era of iTunes, Spotify and Grooveshark, among others, begun, but there are still active users on the site. These users are the reason I felt I had to clear my conscience for barely working on the site for many years. Possible solutions are to make time for the site, take it down, or simply make other people work on it.

I chose the latter. By making the code public at Github, the users themselves get the chance to improve on it. There are however some things you need to keep in mind before throwing your code out there, especially if it is an older project that might not have been developed according to all of today’s best practices.

1. Remove sensitive data

First of all, make sure that any sensitive data is removed from files that will be made public. This includes passwords to your database and mail provider, encryption keys, API keys for third-party services and anything else that shouldn’t end up in the wrong hands. If this information has already been put under version control, simply removing those lines is of course not enough.

The first step is to find all these bits and pieces of information and gather these in a configuration file (or similar) that contains information that should not be available to other people. Make sure to add this file to your list of ignored files (.gitignore, if using Git). I for example had a global salt used when hashing user passwords that was located in the user model, which was under version control.

The second step is therefore to remove all traces of your secrets from old commit data. If you are using Git, then you will use the git filter-branch command. GitHub has a guide on removing sensitive data which is very useful for this. They also mention another important thing, namely changing any passwords used by the application, just in case something is missed.

2. Code review

Grab a cup of coffee. You will most likely need it. The next step is going through your code, line by line, and continually ask yourself, where does this input come from? Am I enforcing any validation on this input? Where is it used? Is it properly escaped?

The goal is of course to cover your bases in terms of SQL and XSS injections, CSRF, session management and all the other possible attack scenarios that are available. For those of you who barely understood what I was just talking about, I highly recommend you to visit OWASP, and especially make sure you grasp the concepts in OWASP Top 10. Actually, I recommend it anyway. These are the must-haves of security.

I, for example, found a SQL injection vulnerability in the record listings. The sorting worked by adding the direction, ascending (ASC) or descending (DESC), to the URL. This parameter was then put directly into the SQL query that fetches the list of records. A stupid mistake, of course, but one that was easy to make, especially when new to the game. Try to patch these things up, so not to make life easier for potential attackers.

3. Upgrade libraries

Once you have gone through your own code, some time should be spent on any external dependencies. Most of us use frameworks and libraries to speed up the development, and especially when a project has gone unattended for a while, these things tend to have moved on without you. Outdated libraries with known security flaws are common points of attack, since the problems are typically well-known and easy to exploit.

Not surprisingly, my site was running version 1.7.2 of CodeIgniter which was released in September 2009. That’s three years ago. The latest update put the version number to 2.1.2 and was released June 2012. Looking through the change log revealed quite a few fixed security problems, as well as other improvements.

Final words

The steps described above can of course be applied to your code base even if you are not planning to go open-source. I don’t believe that open-sourcing code is always the way to go, obviously. The risks must always be weighted against the potential rewards, and these are fundamentally different for a small, non-profit project and a large business application.

On the other hand, I don’t buy the argument that revealing your code would make your site less secure. This concept is called security through obscurity and may work as an additional layer of security, but it does not by itself secure a flawed application.

I teamed up with @rickard_olsson, @jensljungblad and @_sandrahansson with the goal of creating our first Spotify app. In 24 hours we did just that, and the result was a music quiz app called Quizify (the number of apps named -ify was staggering). It was a great hack and we hope to get the chance again next year!

Anyhow! I thought I’d share my experience of doing app development for Spotify.

Resources

The app itself is built purely using Javascript, HTML and CSS which is rendered by Chromium inside Spotify. There are design guidelines that deal with how you should design your app, but the most useful resource is probably the Javascript API.

The Spotify JSDocs are okay. Not more, not less. There is a clear warning on the top of the page that they are preliminary, but more than that, they are very sparse. It’s not a very big API, so it’s easy enough to get around and find what you need, but don’t expect verbose descriptions of methods or events (what’s the practical difference between SEARCHTYPE.NORMAL and SEARCHTYPE.SUGGESTION?). There are code examples for a few common tasks, such as searching and authenticating users using Facebook or other third-party services, but once again they are limited in numbers.

Architecture

To me, Javascript is typically something that is added on top of an application, instead of being the foundation as it is in this case. This probably led to a less-than-perfect architecture. For new projects I would suggest using the index page as a combined layout page and front controller. Layout because it beats copy-pasting all that markup between files, and front controller because any spotify:your_app:param links will be sent to your index.

From there you can load any content you need from other files based on the URL, which consequently means you should use spotify: URIs inside your app as well rather than link to your html-files (which is exactly what we did, unfortunately). This is mentioned fleetingly (sort of) in the integration guidelines, but deserves a lot more attention in my opinion.

Backend

Many apps require a backend, and there is honestly not too much to say here. We used Heroku to host a small RESTful API built in Sinatra and a Postgres database. Just make sure to add the domain of your backend application to the RequiredPermissions in the manifest.json file, because otherwise Spotify will block all your AJAX requests there. The same goes for any outgoing requests, such as third-party authentication. This is covered in the official tutorial, but I wanted to mention it so you don’t forget and spend 20 minutes debugging dropped AJAX requests. Not that it happened to me or anything…

Future

From what I understood, there have been some concerns raised by the record labels regarding the apps. I don’t know exactly why, but I assume this is why there has been relatively little activity since the initial announcement that Spotify was becoming an app platform. It seems however that these issues are soon to be resolved, which hopefully means new momentum for the project in terms of both features and documentation. Perhaps there might even be opportunities to monetize the apps, but I wouldn’t expect that anytime soon.

We had rented a house in Vorupør, population 606, in the Thy National Park. It is not the end of the world, and we could of course have picked up a Danish newspaper whenever we went grocery shopping, and had World War 3 begun we would most likely have heard about it from the locals, but as it was we stayed pretty much in the dark when it came to anything outside Thy.

Before arriving there, I had expected some 3G or at least some EDGE availability (for a price, of course) and the occasional wi-fi connection, but no luck. I suspect the end result was a personal record in the longest consecutive time spent offline, at least for quite a few years, with no Internet for four full days.

Is this really blog worthy, one might ask? A fair question indeed, but I found this experience to be rather interesting because I hadn’t realized how much time I spend online. It’s not only that almost everything I do on my computer requires an Internet connection, but every time I have a moment to spare that does not require my full attention I reflexively pull out my iPhone to check my e-mail, Twitter, Reeder, Facebook or whatever else I haven’t done in the last two minutes. It is an action that is rarely caused by a consious decision, but rather it seems to stem purely from muscle memory.

This idea that constantly staying connected might not be all that it’s cracked up to be is of course not revolutionary. Studies have shown that social networking sites may contribute to anxiety, and even people in Silicon Valley who deal these digital drugs acknowledge the importance of disconnecting once in a while.

I cannot claim to have come back as a completely different person. Obviously I am back online again, and I wouldn’t want it any other way. I do however feel that disconnecting has given me a boost in creativity with new ideas for projects as well as providing well-needed focus on existing problems. Even though it has been almost 24 hours since I went online, I still haven’t even opened my Twitter feed. Not because I’ve told my self not to, but because it hasn’t crossed my mind (until now).

What it turns out I missed the most was actually just keeping tabs on what goes on in the world. Especially since the Olympics were ongoing, it was frustrating to not know what was happening. This feeling was a lot stronger than any thoughts of what people might have posted on Twitter or Facebook (thank God, ‘cause if it hadn’t been I would’ve been worried).

The most interesting part now is to see if my Reflexive Online Refreshing Syndrome (ROFS - I made that up) has been cured or at least lessened for a significant amount of time, or if I will be back to normal in a few days time. Even without any scientific proof I dare go out on a limb and claim that ROFS causes a massive amount of time - and in the end, money - to be wasted both at home and at work, and as such I hope to avoid going back.

Since four day long flight-modes are seldom possible, I will have to rely on common sense. I would love to hear how other people do this. Do you disconnect fully for a fixed amount of time per day? Do you use recurring intervals, such as one hour online, one hour offline? Or do you simply rely on will power to avoid your Internet extravagances?

To avoid manually converting all my posts I used exitwp. Okay, admittedly I was actually in the process of doing this manually when I was hit by the realization that there must be a better way, as it turned out there was. I use Mac OS X Lion which comes bundled with Python, which is neat considering exitwp is written in Python. If you don’t use Mac, you’re on your own for this.

Anyway, start off by cloning the exitwp repo. The program has a few dependencies, and if you don’t already have them installed, the best way of grabbing them is probably using Pip. Pip is a package manager of sorts for Python (I’m not a Python guy) and it will make your life much easier (I guess).

Once installed, run you run the pip install command in the exitwp folder, which installs the dependencies. You are now set for the actual conversion. Below you will see the commands that you either already typed, or will copy-paste in about two seconds.

1
2
3
4

$ git clone https://github.com/thomasf/exitwp
$ curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | sudo python
$ cd exitwp
$ sudo pip install --upgrade  -r pip_requirements.txt

Next step is getting your data from Wordpress. Thankfully the folks at WP has made this easy. Simply log in to your admin area, go to Tools -> Export and grab all your posts as XML. Save the XML file in your exitwp/wordpress-xml directory.

Now all that remains is running python exitwp.py and your posts will be converted to Octopress-compatible markdown files in the exitwp/build directory. Move the newly generated files to your Octopress source/_posts folder and you will soon be able to relax.

By now your blog should be working, and if it doesn’t I’m afraid you will actually have to read the text on all those other sites. A few tweaks remain if you wish to remain somewhat backward compatible when replacing the Wordpress site with your fancy new Octopress ditto.

If you used tags in WP for your posts, the converter will unfortunately still lists them in the post header as tags. You will have to change all tags: to categories:. A quick search-and-replace should do the trick. Secondly, since categories were called tags, and were thus located at /tag/ in the URL hierarchy, you might want to set category_dir: tag in _config.py to remain backward compatible.

Speaking of backward compatability. If you also want to make sure that old permalinks will still work, you might have to change the permalink setting as well. I set mine to /:year/:month/:title/, which was the same as I had in WP.

That was it for me at least. I hope your ride will be just as smooth if you decide to make the switch.

As university, and later work, started taking up more time, I made up for it by doing less when I am not working. Don’t get me wrong, I belong to the group of people that believe that overtime is unproductive and even hurtful in the long haul - all hail the 40 hour week! What I mean is that spare time does not have to equal ass-on-couch-time.

If I were to take the Proust Questionnaire in Vanity Fair (why that would ever happen is beside the point), my answer to the question of my greatest extravagance would have to be TV-shows. I absolutely love TV-shows. Nothing wrong with that, but the problem is that all those 20 or 40 or 60 minutes of TV start to add up when one episode is followed by another and so on. It’s probably not close to crack cocaine on the addiction scale, but it is a time sink.

I am sure that most people have these time sinks, whether it is TV-shows, movies, shopping, sleeping or something else. These are all great things, but I realize that they are well complemented with reading a book (Fifty Shades of Grey does not count) or a magazine (the ones by actual journalists), writing a journal, learning a second/third/fourth language or working on a side project.

Why would you want to do this? It is basically all about self-improvement, and even though self-improvement have become something of a farce with highly paid coaches and quasi-science, it doesn’t take a genius to guess that there is a link between improving upon oneself and your confidence and happiness, which in turn is linked to success. If you are interested in the topic I can recommend both the paper “The benefits of frequent positive affect: does happiness lead to success?” by Lyubomirsky et. al. and the book “59 Seconds” by Richard Wiseman.

Now wrap up your procrastination and go read a book.

MAMP actually comes bundled with Xdebug, though it is not enabled by default. The first thing I did was to upgrade the version of Xdebug to 2.1.0. I don’t think this is required, but it sure didn’t hurt. Just download the PHP Remote Debugging Client from the the boys at ActiveState and replace the xdebug.so in your /Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626 folder (the date on the end might be different, but just go with what you find!) with the one unzipped from the downloaded file.

The next step is to enable Xdebug which we do in the php.ini file. Open up MAMP, select File -> Edit Template -> ‘PHP 5.3.2 php.ini’ from the menu and modify the end of the file so that it looks (somewhat) like the one below. This is just an example however, and these INI-settings are basically a mash-up of all the tips I found while googling the matter. Especially note that the xdebug.default_enable, _ xdebug.remote_autostart and xdebug.idekey_ settings are not mentioned in the NetBeans Wiki’s guide, so it might be that they are not required. Also be really sure the Zend Optimizer line is commented out, since it apparently interferes with Xdebug.

1
2
3
4
5
6
7
8
9
10
11
12
13

[xdebug]
xdebug.default_enable=1
zend_extension="/Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_log="/var/log/xdebug.log"
xdebug.remote_host=localhost
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.idekey="netbeans-xdebug"

[Zend]
;MAMP_zend_optimizer_MAMP

After this step I wasted a lot of time on trying to find out why NetBeans couldn’t connect to Xdebug. Finally I rebooted my computer and everything was suddenly working. My best guess is that this was due to a conflict on port 9000 (possibly with Skype). Feel free to try it out with only restarting the MAMP server but remember to do a full reboot if things still aren’t working.

By now you should be up and running. NetBeans debugging functionality is pretty straightforward, however you might want to check out the official documentation to get started. Hope this saves someone else a few hours, and feel free to share your tips in the comments!

I guess most people have heard of the amazing (and free!) Dropbox. In short, it is a file sharing service that integrates directly with your file system. Simply drop a file into the Dropbox folder and - wham! - you can now access it via the web, a mobile application or another computer, or share files with your friends and family. Other applications can utilize this great feature, and one of those is PlainText. It is an iOS text-editing application that syncs all files using Dropbox.

One lacking feature of PlainText though, is that it does not give you the option of sharing files and folders with others, which would be really useful for, say, grocery shopping. I realized it would be pretty sweet if whenever Emelie or I thought of something we needed to get at the store, we just wrote it down in an app and both of us would have instant access to the list, so it wouldn’t matter which one of us went shopping. Since PlainText uses Dropbox, this is in fact a rather simple thing to set up.

First of all I created a new folder in PlainText, since I want easy control over which files to share. This folder will be synced using Dropbox so after it has been created, manually share the folder with whomever you’d like either by right-clicking the folder on your computer or via the web interface. When you share a folder within another folder, the receiving user will have it appear at the lowest level in his or her Dropbox folder structure, so make sure they move the shared folder inside their PlainText folder.

And, voilà! Time to get the freaky co-editing started! If the folder does not show up, or disappears after it’s been shared, do a hard restart of the application on your device. It did the trick for me.

Do you have a nice Dropbox trick? Or simply know of a free app that does this same thing, only ten times better? Share in the comments.

For all this time I have been lazily reading and composing mail, using a few filters to get those incoming messages bagged and tagged but keeping every single e-mail in the inbox. It was only a month or so ago I realized the beauty of the Archive button, which was only sporadically used before. Since then I’ve got a very clear work-flow for dealing with all my mail.

The main goal is to keep your inbox empty. If you haven’t seen an empty inbox since the last trembling months of the last millennium you have no idea what you’re missing. It really gives a feeling of peace to see that nothingness stare back at you - no judgment for not replying, no expectation to be populated, just a blank slate. This is not always possible though, but most of the time I do manage to keep it empty.

Whenever a new e-mail pops in, I read it. Now, that’s not so hard? Once read I decide if I can answer it right at this moment, and if I can, I do. Thereafter I archive the conversation and move on. Archiving obviously also goes for informational messages that does not need any reply. Those e-mails that I expect to be able to answer in the next day or two are allowed to remain read in the inbox. That’s pretty much it!

Now, you may ask yourself “How about e-mails that I won’t be able to give an answer to until a further date?”. The answer to that is for you to reply immediately and write exactly that, and we are magically back to step one. For those really important e-mails that I might need to reference for longer periods of time I like to use the Star feature of Gmail.

Is the clutter-free inbox the way of the future or a pointless Getting Things Done-inspired waste of time? Go for comments.