Lessons learned
With the past two years, there’s been an incredible development in my experience and knowledge as a software developer. Still, it’s important to look back at ones mistakes and learn from them.
I still have the complete source code and database of my very first large scale program. The year was 2007 (I think) when I first discovered the Dragon Knight open source MMORPG project. In no time at all I had the system up and running in localhost and the next summer (or two) went into learning web technologies, programming and CS in general.
Now, as part of a software testing course assignment, I had the incentive to look back and write down some notes.
- Don’t use PHP closing tags in php-only files
- If you have a single entry point (framework index.php), do a check in the first line of every file that the entry point is used. Kohana does that with a constant defined check that dies on failure.
- DRY: put config into one place
- Use InnoDB relational tables
- Don’t mix Models, Views, Controllers in a single file – use arhitecture. It’s also DRY!
- I18n mostly everything. You don’t have to actually translate it, just make it translatable in the future. In Kohana: use the __() function. For javascript, find a library.
- Keep font sizes and color contrasts readable
- Always let the user visually distinguish where (s)he is in terms of navigation. Breadcrumbs are a good idea. Back links should be present in multi-staged navigation. Logo should link to the index page. The user shouldn’t feel lost.
- Main navigation should be visible on all pages (there are justified exceptions)
- Be consistent: an UI element that act the same should always look so, too. Don’t make one link blue, the other green, if they behave the same. DO make a link red if it’s dangerous, but not simply for fun.
- Avoid opening multiple popup windows, use modal dialogs, tooltips, javascript plugins to present the information. When you do open a popup, make sure it’s sized so that the user doesn’t have to resize it to see the whole content.
- Don’t hardcode system messages via a query string (…&messageID=1) (nor ?message=Please+Try+Again)
- Test against security vulnerabilities! Malicious input (injection, XSS) in particular.
Scraping for grades
itk_grade.rb output
The student information system (ÕIS) our college is using satisfies most (if not all) the requirements presented to it. Still, I found a fault: there’s no API and I wanted to get notified ASAP when a new grade is added.
Some background: I recently started a wonderful online learning course: SAAS-class.org (https://www.coursera.org/saas/class) where I got the opportunity & incentive to dive into Ruby (on Rails).
So, my first ever Ruby class was born. The code uses Mechanize to log into the grade system, navigates to the correct page and scrapes the grades into an Hash structure. The end user can basically just do this:
require "itk_grades"
# Create instance and save login data
ITK = ITKGrades.new("user", "pass")
# Fetch & scrape grades from ÕIS.
ITK.fetch
#ITK.grades # Returns a hash of all grades
# Print all grades
ITK.print
You can see the full code over @ GitHub or the college Wiki (in Estonian).
Python: Check that your projects are still alive
I wrote the following Python script to solve my need to verify all my projects are still up and running. The program itself is simple: given a list of URL-s check that all of them return HTTP status code 200 (OK). On any other status (mainly 500) send a report to the admin.
Best used via crontab every… minutes.
Install: Copy both files to a directory (~/bin works well) and check that dependencies (imports) are satisfied. Configure via http_check.yaml, optionally adding custom actions to http_ok() and http_error() functions inside the main script file.
Link to the source (GitHub)
His first program…in about half an hour
- Joonase’s first ever WPF application
Count on me to tutor all willing in the art of programming. I let my younger brother play around with Visual Studio 2010 and provided the necessary tutoring. He managed to create his first ever program in about half an hour.
Programming is not as much knowing the syntax of any particular programming language than it is creative problem solving. Visual Studio is a good example: anyone can drag and drop form elements to an empty canvas, but correct mindset is needed for them to actually form an useful and usable application.
The same can be said for any other programming environment. I’ve discovered that I spend more time modelling, thinking and experimenting than I use for coding any particular feature.
Download my brothers first WPF application from here (.exe, 16kb). The program is an average grade calculator with subject names on the left and final marks on the right.
Modernizer is awesome.
I absolutely HATE supporting IE < 9 designs. It's tedious, frustrating and no fun at all.
I'm designing for HTML5 and CSS3 (the "new" web is here now) and nearly always use the new features both language upgrades bring to modern, sensible browsers.
That's why I've been using Modernizer as part of the HTML5 Boilerplate suite by Paul Irish.
Modernizer To the Resque!
Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.
- modernizer.com
At first, I took it's promise for automagical compatibility improvements with ehem… older browsers… at trust… but then I fired up my virtual machine and saw the real difference.
Below are 3 pictures of a design I am creating in HTML based on specs from the designer. You decide: is Modernizer 2.0 worth the 10 kilobytes of JS?
(Above) Firefox 6 – How It Should Look
(Above) IE 8 In a Virtual Machine With Modernizer 2.0
(Above) IE 8 In a Virtual Machine Without Modernizer
The Morale
A good way to spend the weekend – Garage48 Tartu 2011
Intro
Just Grab It
Mobile app that allows you to scan products and add if you like or dislike them. With the Just Grab It application you can easily organize your items to remember and recommend later.
- URL: http://justgrab.it/
- Facebook: http://www.facebook.com/Justgrabit
- Twitter: http://twitter.com/justgrabitapp
- Team: Lauri Saidla, Martin Kangur, Margus Pala, Ando Roots, Esko Felin, Jaanus Jagomägi, Zahhar Kirillov, Mehis Pärn
This year's second #hackathon took place in Tartu University Faculty of Mathematics and Computer Science. As usual the teams were locked in a building (some more than others) for 48 hours and a weekend to try changing the world with the help of an overflow of Red Bull and snacks to go with it.
I'd hereby like to give some constructive criticism to those who feel they need it. These are my notes from during the initial pitching:
Pitching
- Do NOT turn your back to the audience to look at the slides. If you need to point at something, do it from the side. The slides are for the listeners to grab the key points of your talk. If you can't help yourself, use no slides at all or a static representative picture.
- Turning your back in effect loses your connection with the audience thereby decreasing any credibility you might have gained with your pitch. I joined a theater troupe and they made me quickly lose the bad habit. Again, this is important – don't stand with your back to the audience.
- Since we're already on the topic – a lot, and I mean A LOT of pitchers had a whole essay written on the slide up to a point where I though I was presented with an scientific article. The slide is meant as a supportive asset to back up your words, not the other way around. Thereby the reason for the repeating questions from the jury/audience: "…but what does it actually DO?"
One of the best ppt-s I've seen in my life had just one to five words on a plain background written on each slide and the charismatic speaker used them as slides are meant to be used. Less is more. Look to Google for inspiration.
This is my biggest rant about the weekend. I understand there were practice pitches earlier. Clearly they weren't through enough or the presenters themselves are to blame. The speakers in Helsinki (October) – use the constructive criticism. Also, since I got an inkling that I'd like to pitch myself soon too – use these words against me when the time comes.
- It was a shame to see a pitcher talking to the floor. I understand uncertainty better than most, but you have to make eye contact with your listeners – the people you're convincing to trust and invest in your idea.
- Be concise. 90 seconds is not a lot of time and as with the limited number of slide
syour words have to carry. To use fillers and tons of text is to kill the otherwise solid idea. Dead. Gone.
- Every single person who made the pitch – especially those not on the field of IT – deserves credit for their courage. So when it's actually your turn, I dearly wish you thought of something to say – not be forced to admit after 1/2 of the allocated time: "…that's basically it". If you're scared, start with a joke or two. Or let the slide do it for you in a subtle manner.
- Scary big auditorium. Lots and lots of people. Mic there for a reason.
There. Got it out of my system.
Friday: Day #1
The forming of teams in the style unique to G48 went… well, in the end everyone had teams. For a long time I had no idea which project to join, but then an interesting challenge popped up and I went for it. As always, some teams were at maximum capacity, some were disbanded, but every idea that deserved to live got it's chance.
There were 8 of us: team JustGrabIt – 2 designers, 2 back-end, a marketer, a visionary/project leader, an Android developer and a cross-functional do-it-all, hack-it-all IT guru. A full team. The idea itself can best be explained by it's website, but basically it's am Android slash web application for FB style (I do hope they didn't coin the term) like/dislike of real world objects.
The first evening ended about 2 in the morning with Kohana (more about my love for it: That’s how easy it is to create Twitter with Kohana 3) and the environment set up, some of the MVC files written – basically being ready to fire at the task ahead at full speed. We used GIThub for VCS and I was unhappy to see yet another person struggle to install it (and Apache2) on The WB OS (World's Best Operating System).
Sleep awaited on the hard floor of the lecture hall upstairs. I love G48 for leaving the venue open for (24 + 24)h. As expected, Zzzz… was one of the commodities not easily found as opposed to food and coffee which were always plentiful. I think we all suffered a minor case of sleep deprivation, but I'm totally fine with it.
Saturday: Day #2
Fast-Forward the next day: Early awakening, coffee and coding. And coding. Basically,
for (;;) code();
Our team was so big, we had 3 'departments': back-end, mobile, marketing. Communication wasn't an issue with a project manager in charge and I was only too eager (maybe a bit too so) to take the reins on the architectural level.
My programming buddy had a background of Ruby and PHP so we got along fine (is it true that Java and PHP fightalot?). Here's an interesting thought: even though he's teaching programming as a professor, even he couldn't crack Facebook login – but not for the lack of trying. I've chatted with and heard other developers complain about the same fact. It's like being in Quirks Mode all over again.
One of the good things that came out of the weekend was the new experience I gained with building API-s. Now I've been on both sides: the user (front-end developer) and the designer and realized I like the role that gets less comments and more complaints from the end-user better.
I'm regretful that I didn't use TDD. I know it's prototyping and all and we are supposed to YAGNI, but I'd still have liked to have at least a minimum amount of certainty in my code. Only one thing standing in the way: Kohana's (or rather, PHPUnit's) inability to make database driven application testing understandable and easy.
I've tried to follow Sebastian Bergmann's tutorial, but quite frankly, it's confusing as hell, forcing me to deal with XML and god knows what. If only there were such a thing for Kohana + PUnit like YAML database setup-teardown…
The lack of tests got me in trouble, ultimately resulting in an error being said (at least we commented out such debug messages like 'you suck') during the live demo. Still, I'm pleased with the work I did and plan to smooth it over when (not planning to leave another project hanging) I have the time.
Stayed up late (late for programmers usually means ~4am) with The Guru, trying to track down an image upload error. Did you know that you can capture and upload images from Android to an API as a base64 decoded string? Did some more work the next day and finally, just before the demo, wrote some JavaScript for a change.
Sunday: Day #3
There's always a frustrating bug in the code you get over and think that's the biggest obstacle but then come the frantic moments as the clock ticks mercilessly down and you silently say "FUCK!", get out your earplugs and dive into it. Which, by my careful observation of at least three designers is exactly the way to go to be productive.
Good design is very important in selling your idea. The implemented solutions ranged from no design at all (well, the bare minimum) to some really beautiful stuff, but in the end it's about delivering the functionality without sacrificing usability nor repelling users by not having something for the eye to rest on. Claim: everyone appreciates art in some form or the other, be it classical music or GUI button design. Compliments to both of our designers who not only knew what they were doing but weren't afraid to write the needed template code themselves to implement it when the main coders were otherwise occupied.
It's amazing what you can accomplish with 48 hours of self-sacrifice and dedication towards a common goal. The finished (or pieced together just for the demo) apps were up to the challenge and in my subjective opinion, three-four of them stand a real chance of starting something awesome.
Our team didn't win any prices, but that's okay. Often, it's not about the goal after all… and when projects die or are murdered, successful social ties remain… and good implementations rise to prove themselves.
Wrap
Garage48 was what I expected it to be – a draining weekend of fun and professional challenges coupled with learning. Eye-opening perspectives from the mentors were appreciated, good-natured mockery equally so. I hereby state that the organizers are awesome and deserve my respect as long as they have it within themselves to continue what they do… and a bit longer.
G48 is a wonderful chance for anyone with an idea – not just IT people – to come forth and give it a shot. If the outcome isn't what expected, you've learned something. If the project soars… who knows – maybe you're the next Rovio and just shake it.
Inspire. Teamwork. Solve. Conquer.
Relevant links
Garage48 Tartu 2011 Projects Launched
Garage48 Tartus: arendamisel on 14 projekti!
Garage48 võistluse võitja aitab lühendada järjekordi
About The Author
Ando “David” Roots is a college student and a software developer from Kunda, Estonia. Living, working and studying in Tallinn, he hopes to get his bachelor degree from the Estonian Information Technology College on IT Systems Development. 