standards

Aggregating feeds isn’t all that simple

As I mentioned a few times, one of my first start-up ideas was an RSS aggregator. It was back in 2005 or so, before Google Reader was even alive. Bloglines was the coolest tool, if I remember correctly, and it sucked badly. I got together with a few friends of mine and we started coding. It was an interesting challenge both technically and aesthetically. But we got it to the point where it actually worked and wasn’t all too bad. It was a weird mixture of Python, Perl, and PHP though.

Eventually, it became too much work. We couldn’t figure out how to monetize the thing. And Google Reader was announced. That sort of killed the project.

A few month back, when the announcement of Google Reader’s end of life came out, I looked at the alternatives and wasn’t pleased. I thought with all the technical advances in the last few years, and with my own improved knowledge, I could attempt the task again. Yes, I know, I am hopeless optimist in a lot of matters.

At least this time it took just a few days to convince me not to pursue the goal. Alternatives are plentiful. Each and every one of them is light years ahead. I still don’t enjoy front-end development. And I still have no clue as to how to monetize it. So, the Subs Reader got frozen. At least I got it all in frameworks, and left it in the Open Source state. If I ever will have another try, I can pick up from here.

One of the biggest mistakes I’ve done the last time, was not documenting the project’s process at all. I vaguely remember that I didn’t sleep for a few nights, trying to figure out all kinds of problems. But what were they, I don’t remember.

Today, I came across a blog post which lists similar problems that I had to solve, but in greater number and variety. Even if you aren’t thinking about writing your own RSS reader any time soon (or ever), you should still read through the Brian’s stupid feed tricks. First of all, they clearly illustrate how much complexity is hiding in the details. Secondly, they show non-standard is the web in general and RSS in particular. If you do any kind of web crawling, you’d probably see half of the same issues in your application. Thirdly, even if you aren’t crawling the web at all, but just code a web application or an API to one, you’ll many places where you can go wrong without noticing it. All in all, it’s a great list of problems that everybody involved in web development can learn from.

Religious programming

Here is a snippet of discussion I had with a colleague today. I thought it was funny:

[2:59 PM] Him: this is your prob:
[2:59 PM] * Him sent file IMG_04092012_145925.png.
[2:59 PM] Him: “&” is not valid char in xml
[3:00 PM] Me: hmm
[3:00 PM] Me: how do you know? :)
[3:00 PM] Him: i prayed to the lord and he showed me the way
[3:00 PM] Him: you didn’t, right?
[3:01 PM] Me: I have a different lord apparently :)
[3:01 PM] Him: your lord is not a programmer!
[3:01 PM] Me: no, my lord can parse & in xml just fine … your lord is a pussy :)
[3:02 PM] Him: lol!!

HTML5 splits into two standards

Just when web developers got a little bit of hope, Slashdot reports on the bad news.

Until now the two standards bodies working on HTML5 (WHATWG and W3C ) have cooperated. An announcement by WHATWG makes it clear that this is no longer true. WHATWG is going to work on a living standard for HTML which will continue to evolve as more technologies are added. W3C is going the traditional and much more time consuming route of creating a traditional standard which WHATWG refers to as a ‘snapshot’ of their living standard. Of course now being free of W3C’s slower methods WHATWG can accelerate the pace of introducing new technologies to HTML5. Whatever happens, the future has just become more complicated — now you have to ask yourself ‘Which HTML5?’

Even if it sounds good, it is actually really bad. HTML5 is already complicated enough, and all major browsers support a different subset of it, and even those things which are supported do differ in the way of how. Splitting the standard just complicated things further. The fact that this is not exactly new, doesn’t really matter. Saying that it won’t be harmful, is silly. As is the whole point of a “living standard”. Like a few people mentioned in Slashdot comments, “living standard” is an oxymoron. The whole point of standard is to provide a static point of reference. Splitting is not a solution to the problem. It’s quite the opposite. Consider this xkcd comics for illustration, which is nothing but the truth.

PSD slicing service recommendation

This is a follow-up to my recent post “MostSliced.com summary – picking PSD slicing company“.

Once the choices for the PSD slicing service were established, I did the next step – actual order. I started from the top of my list, which happened to be xHTML Master. I sent them the order through the form on their web site and got a pretty fast response apologizing for the fact that they were too busy to undertake my order. No problem. Good that they notified me in a timely manner. So, I went to the next choice – PSD Slicing. Again, submitted the design and went into the waiting mode.

Pretty soon I received an email letting me know that the order is OK and that they can start on Monday (next working day) and finish it by Wednesday (two pages, with one of them being a rather complex design). The timing was well within my limits. I sent them 50% of the down-payment and started waiting again. Today, on Tuesday, around lunch time, I got my order back, fully done and finished.

First of all, of course, I was a bit surprised with the speed. I thought it would take them more. When I checked the results I was even more surprised. In short: outstanding job! The images were cut properly, some in PNG, some in GIF, some in JPG – properly chosen each time. The xHTML was small and clean, validated perfectly with XHTML 1.0 Strict (not even Transitional!). DIVs, proper CSS, nicely indented. CSS was also done nicely – small, simple, and straight-forward. Fully valid. Also, the whole codebase is pretty semantic and, as a bonus, validates with web accessibility standard (Section 508). To say that I was really impressed with the result was to say nothing at all. I was stunned for a few minutes. It’s been a really long time since I saw anything so beautiful.

It was so good that I couldn’t believe it. So I thought maybe it will break in one of the major browsers. Then my attention was caught by something else in that email message that they sent me. It was a link to BrowserShots.org , which is the web service that can show you how your web site looks in a whole lot of browsers. PSD Slicing provided me with the link to the screenshots of their results in all major browsers that I cared about!

After checking that code back and forth, the only suggestion I could come up with is … comments. They aren’t required or anything, since the whole CSS and xHTML files are very small (something around 6-10 KBytes), but still it would have been nice to have some comments, especially in CSS.

Am I satisfied with their service? You bet I am. Will I ever recommend it? Yes, of course. I’m doing it already. Is it worth the money (around $120/page)? Yes! [insert more questions here and answer them “yes”]

Just ignore HTML 5 for now

A List Apart has a little introduction into HTML 5. They explain the tough process of crafting the standard, how different parties interact, and what they are trying to achieve. It all sounds pretty interesting if you have no idea about HTML 5. Also, it all sounds pretty interesting until you get to one of the final paragraphs (emphasis is mine):

Work on HTML 5 is rapidly progressing, yet it is still expected to continue for several years. Due to the requirement to produce test cases and achieve interoperable implementations, current estimates have work finishing in around ten to fifteen years.

Excuse me? They are working on a standard for the Web, one of the fastest growing, expanding, and developing areas of IT industry, which itself is one of the fastest developing industries of the modern world, and they are planning to finish in 10 or 15 years?!! Hello? Wake up!

Just take a look around. See how this place is different even from two years ago. See how dramatically different it is from five years ago. See how it is unrecognizably different from what it was ten years ago. Try to find a living human being who even remembers how it was fifteen years ago… Guys, what are you doing over there?

No matter how well you plan things today, no matter to how many people in the field you talk today, there is absolutely no way to predict how things will be in ten or fifteen years. Trying to predict this will hard enough job for a single head. Getting a few heads to agree on how this will be is beyond impossible!

If that’s how long HTML 5 will need to come out, we can just drop the effort right now. If it will even come out, it will be totally useless, because people won’t wait for it. If you think that we are moving fast now, you haven’t seen nothing yet. We are just starting. We are in the 1950s of the automobile industry. Web is still a very much foreign concept for our society. Wait a few more years when it will get more natural, and you’ll see what are the real power and speed of development.

Nobody is going to wait for a bunch of guys to agree on something that nobody knows how will come out. People will just come up with their own solutions to their problems. They will aggregate, re-factor, and re-optimize those solutions until they solve the majority of problems. And then they will move on to the next stack of problems. And will go on and on. Forever…

How important is HTML 5? It is needed, yes. But right now. Not in five years, not in ten, and not in fifteen. The problems it tries to solve are the problems of today. If it’s not coming out shortly, you can just ignore it altogether. There will be another solution…