A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.
Why are software development task estimations regularly off by a factor of 2-3?
Excellent Quora thread with many solid examples and explanations.
Developers are also the only group where they are asked to do something which has never been done before, and tell someone else how long it will take before they even know what actually needs to be done.
By now you know that I can’t praise GitHub enough. It is one of the best tools for developers ever. Seriously. It’s up there with git itself, and even Vim. If you aren’t using it yet, stop whatever it is you are doing and rush there. Now. I’m not kidding.
So, anyways. Today GitHub added another awesome feature – Releases. These are basically git tags on steroids.
I’ve been already playing around with the idea of releases for our work projects. See, for example, phing-version branch of my sandbox repository. It worked, but it’s not perfect. With GitHub Releases however I’ll have pretty much everything I need – release notes, easy full diff reviews, binary attachments, etc.
A little side note for binary attachments: I mostly work with PHP, which doesn’t really need binary attachments. But I am a part of other, “heavier” projects, developed in C++ for example. This feature will come in handy. Also, as far as PHP goes, I was playing with the idea of using RPM and YUM as a mechanism for managing installation, upgrade, and downgrade process.
Back to GitHub Releases now. This is an excellent example of why you should use GitHub instead of setting up your own environment. You’ll waste more time and money. It will be ugly. And you’ll have to maintain it. With GitHub you’ll focus on your actual development work and will get excited every now and then when they add a new feature.
Fedora 19 has been released a few hours ago. This is one of the most interesting releases, feature-wise, for me personally. Have a look at the announcement, and scroll through the full list of features that made it through. Here is what I’m going to be looking at first thing tomorrow:
Yet again huge thanks to everyone who made this release possible. You guys are awesome, no matter how much or how little ranting will come in the next few days.
The OOP in PHP by Matthew Turland
A well all around presentation on Object Oriented Programming in PHP, including also some of the recent functionality (up to PHP 5.5).
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.