(Sorry, content in german only for this post)
Ende 2007 habe ich bei 9elements einen Crashkurs zu Ruby on Rails gegeben.
Da mich inzwischen schon mehrere Leute gefragt haben ob ich die Folien nicht mal rausgeben möchte tue ich da jetzt.
Die Folien sind extra so gestaltet dass sie auch ausserhalb des Vortrags als Nachschlagewerk für Ruby dienen können.
Der Rails-Teil ist ein arg knapp gehalten und kann mehr einen groben Überblick in den Aufbau des Frameworks geben.
Ruby & Rails Extremcrashkurs (PDF-Link) v1.0 27.03.09
Today Smashing Magazine published an article I wrote last week about Ruby on Rails.
Instead of just doing another tutorial, I gave a rough overview of how Rails works,
together with a lot of praise of the language and the framework.
I tried to spark interest in Rails and Ruby and judging from the first comments I think it worked :)
The text released today is only the first part, covering just enough Ruby to understand the second part coming out next week. If you like the article, please digg it or promote it on reddit/delicious/slashdot.
Thanks to a patch from Kevin Valdek rest_in_place now comes in three flavours:
Prototype, jQuery and mootools.
He also was so kind to improve the included testapp a little.
Please check out the changes at http://github.com/janv/rest_in_place/tree/master
and on the project page.
Convenience vs. validity
Regarding the project page.
In itself it’s kinda pointless since it contains nothing more than the readme which you can also see in all its glory over at github. But it’s invaluable for feedback through the comments. Wincent Colaiuta posted a remark about the standards compliance of the custom attributes RIP uses, which I have to admit is kinda valid:
Haven’t looked at the code yet, but I like the idea very much.
The only problem is those non-standard attributes that you’re jamming into the divs and spans are not valid HTML (well, I admit, I only checked them with an XHTML validator; I don’t actually know if they’d be considered valid for any particular other version of HTML or XHTML).
For me that’s a bit of a show-stopper, as I don’t want my pages spitting out validation errors if anyone feeds them into a validator.
Other than that, looks like a great idea though.
However it also kinda isn’t.
I replied:
I understand your concern but let’s be honest for a minute ;)
These additional attributes might be undefined in XHTML but are syntactically correct and will just be ignored by browsers. They provide a very convenient and concise way of specifying how to edit the fields.
They pose no actual harm to a user’s browsing experience. Neither directly (in the form of malfunctions) nor indirectly (like what the widespread use of really ill-formed HTML did to web development in the past).
As a computer scientist I understand the desire for absolute correctness.
But as an actual application developer, my users are my target audience, not fellow nerds who like feed my pages into validators (no offense).
A little pragmatism can’t hurt once in a while if you want to get things done.
Is this a case of correctness for the sake of correctness?
Or were it little steps like this what led us to the browser wars and IE6?
Should REST in Place give up convenience for the sake of correctness?
How do others deal with inofficial attributes. I know a lot of people and a lot of situations where they saved developers a lot of time and headache.
Ever since I began enjoying photography in June 2006, shortly before purchasing my Nikon D40 (my very first DSLR) I was interested in how other photographers deal with the amount of pictures a digital camera allows you to take.
I’ve learned since then, that the best way to do so is to carefully select you shots before hitting the trigger, but still what do you do with the remaining shots in post processing?
Lightroom offers several methods for organizing photos and I believe Aperture provides something similar:
- Images can be sorted into folders that correspond to folders on your hard-drive
- Images can be tagged
- Images can be rated from 0 to 5 stars
- Images can be picked or rejected
- Metadata can be edited
- You can create virtual copies of images
That’s quite a lot to worry about and for a long time I couldn’t imagine how to use all these options properly.
But I think I finally figured out a way that works for me.
What works for other may differ, especially the purpose of your photography is different.
I’m doing this only for fun on private occasions with a relatively low numbers of pictures per “shooting”.
A professional probably has a different workflow but for beginners looking for ideas my workflow might provide some orientation.
Import
I have my Mac configured so that it opens Lightroom when I insert the SD Card from my camera into the card reader.
To do this, open the Image Capture program and select Lightroom in the preferences.
Lightroom itself is configured to open the Import dialog when a card is inserted.
This way I only need to insert the card and whatever I’ve been doing before, the Lightroom Import dialog pops up.
For maximum convenience, I’ve set up Lightroom so that it even ejects the card after the import is done.
During import I store the images into folders that are hierarchically organized by date.
In my photo folder I have 2 subfolders currently, “2008″ and “2009″, each of which contains folders
from 01 until 12 for each month, and each of those — you guessed it– contains folders for my shootings,
prefixed by day like “2008/08/01 - Barbecue Party”.
I rarely have more than one “shooting” per day. If I do, I append letters to the day, like “2008/12/24a - Decorating the tree”
“2008/12/24b - Christmas Eve”.
Rejection
In the next step, I set up Lightroom to only show unflagged photos and begin looking through all of the photos
with the filmstrip displaying at the bottom of the screen. My goal here is to sort out any pictures that are garbage or duplicates. Unusable stuff gets marked for deletion with the X key. Duplicates (usually from shooting people in continuous mode) are reduced to a single best shot by deleting the excess ones. If I have several very similar shots that I don’t want to throw away, yet also not deal with individually, I group them by selecting all, going to the best one and hitting CMD+G.
After I’m done, the rejected photos are deleted for good by pressing CMD+Backspace
Tagging
In the beginning I didn’t use tags because I could easily keep all my shootings in my head but since my first photos in Lightroom half a year has passed and I don’t really remember them anymore. Now’s the time I wish I had used tags back then. I tag photos by location, by subject (if it’s a person or something significant), by event, by purpose or by any other criteria that I might some day use to find those photos. Generally, I find it pretty hard to come up with good tagging schemes. This is somthing everyone has to learn on his own I guess, find a system that works.
Rating
For rating, I collapse all stacks (grouped photos, via “Photos” menu).
Then I go through the photos and assign stars via the following scheme:
- 4 stars: best shots of the series, the ones I would show someone who doesn’t have a lot of time.
- 3 stars: good shots, ones I would show someone who won’t be bored by them.
- 2 stars: mediocre shots that are too boring in the context of the entire series but might have specific features in them I personally like.
- 1 stars: bad shots. Not deleted because they might show people I like or contain memories or any other reason to keep them but are not even looked at by me unless I specifically search for them.
Then I look at the 4 star photos and give those a 5th star that qualify for my all time best shots.
The overall goal here is to reduce the amount of images. Say, I have a hundred images of a given event.
Someone interested in the event will NOT want to look at all the pictures. Someone who wasn’t there might only care about the 15 best shots, while someone who was attending and whose interest is higher will pobably want to see the 30 best shots.
To the first person I’d show the 4-star photos, the other person would also get to see the 3-star photos. And I probably only want at most one, rarely even two photos of a series in my 5-star all time favourite list.
Picking and Collections
I rarely use these two features. I can imagine how picking could be useful if you intend to throw most of your taken pictures away during import (as opposed to keeping most of them like I do). I have found another use though:
If I export my photos to a photo sharing site or for a friend, I use picking to select the photos I want to use.
When I’m done, the Picked-flags can be removed again.
If I decide that I’ll use one of the selections made this way again at a later time, I create a collection from it.
The tools Lightroom provides are extremely flexible. This can be overwhelming at first and it takes time to develop an effective workflow that combines the needs of the photographer with the options provided by the software. The result will likely differ from person to person. The presented way is one that works well for me and might work for many other beginning photographers but you should feel free to explore other uses for Lightroom’s tool.
I’ve given Sebastian Deutsch write access to my dbserialize repo on github and a few days ago he already made some minor changes, mainly improving the documentation and making the interface more consistent.
Dbserialize provides two rake tasks to store your current environments database tables to Yaml fixtures in db/fixtures and to fill the database with these fixtures.
That way it’s possible to store sample data consistently in the repository and for all developers on a project to use common sample data instead of manually generating something on every developer machine or sending database dumps around via email.
Check out the announcement here, the project page here, and the repository on github
No, not of my blog!
Quite the contrary, I plan to slowly increase my blogging frequency and extend my topics beyond software.
No, the end of my time at Dortmund Technical University is in sight. Yesterday I registered my diploma thesis which I have six months to work on from now, with a deadline of July 20th.
I’ll probably even blog about my progress here since the topic is something a few web dev fellows might be interested in: A thin Web Application Framework based on Serverside JavaScript
06.12.08
This was long overdue but I finally got around to it.
REST in Place is using JSON instead of XML now. A lot of people seemed to have problems with XML, especially those using the Prototype version.
I also included a small testapp in the repository. It is not meant as a tool for TDD or regression tests, just a playground for further development and an example for people using the plugin.
I updated the README and the project page with new information. The README was also missing the CSRF part in the example which I believe caused confusion for some people.
I have begun writing a Haskell library to remotely control Lego Mindstorms NXT Bricks via Bluetooth. I just uploaded the repository to github at http://github.com/janv/haskell-nxt.
The library is far from complete, there’s lots and lots of unimplemented commands and it’s not even working with USB-connections yet. It doesn’t run on windows since it communicates via POSIX device files. Don’t ask me how to create these on Linux, it was dead-easy under OS X.
But release early, release often they say, so here you go.
After using Mercurial for 7 months we at 9elements have finally given in to the internet peer pressure und switched to git (Well, to be honest, several shortcomings in Mercurial played an important role too). Since then I’ve become accustomed to git and today ported over REST in Place from Subversion to Github.
The Github project page ist located at http://github.com/janv/rest_in_place/, the repository can be found at git://github.com/janv/rest_in_place.git.
I’ve updated the README and the project page with the new information.
I’ve also published my dbserialize plugin at Github.
Why didn’t ANYONE notice how FUCKED UP this is:
These factors led to the development of Automake. automake, like autoconf, is a program run by a developer. The developer writes files named Makefile.am; these use a simpler syntax than ordinary Makefiles. automake reads the Makefile.am files and produces Makefile.in files. The idea is that a script generated by autoconf converts these Makefile.in files into Makefiles.
… which are then read by make to run the compiler.
Seriously, if a build process needs 5 different programms in 3 different languages that, in part, generate each other, change the god damn build process to something simpler. So I don’t have to deal with this crap in 2008.
(from http://sources.redhat.com/autobook/autobook/autobook_10.html#SEC10)
