Actually I thought to do it in PHP, but for security issues and also for improving my Python skills I decided to do it in Python. The first problem already was finding a module that can read out the EXIF data of images. After trying pexif I was a bit disappointed, it just couldn’t read my pic’s data. There were some tags it couldn’t handle, so it just stopped with an exception. Then I was going to try jpeg a simple module, there I read in the docs that for doing this and that you should use http://pyexif.sourceforge.net - ok, now I know what I need. Actually it was clear that the module would be named pyexif, but for some reason I was not searching for it. So I downloaded it and thanks to sourceforge this didn’t take less than about half an hour. After unpacking and skimming through the files I was astonished that there was no setup.py. Ok, back to their project page and read a bit again. Oh great, the last comment in big red letters (from 2002) said that they hadn’t done anything on the library for a long time, f***. And I should go and check out “Gene Cash’s EXIF.py library”, which I finally found here. To judge by the comments this one has also been last updated in 2004. Oh man, I think I am going back to PHP, there will surely be up-to-date libraries. But I will give it just another chance, let’s see if there are going to be any interesting hints and/or comments to this entry, hopefully about new modules I didn’t find. Disappointed …
But I am still looking for an event that tells me when the map has completed loading. It just is not very nice when I want to rely on showing something on the map for a while, but I can’t even figure out when it is completely shown to the user.
The property map.tileImages doesn’t seem to exist anymore in v2, it somehow didn’t work anyways. I had tried it and the complete property of the images was always true, for some strange reason. Just for the info: you can access all the images via map.tileImages[0..3][0..3].overlayImage. There are four images in each array and I guess they are for the different kind of view types and the map always consists of four images, but I can’t tell for sure, since I quit experimenting when I found out that complete was always true. So this info was not leading to my goal. I keep on looking.
Unfortunately the info available on the net are not very exhaustive, may be google just wants to hold back some info to assure that noone does what they will do next. Mmmmh, that is very bad thinking :-/. *slapmyself*
Another one of those standard AJAX components is the edit in place method.
Don’t you agree, that editing data used to be really painful? It was always this looong story: clicking the edit button behind the actual data, showing a form that allows us to edit all the fields, submitting the form, getting back the validation message(s), finding the wrong field, edit again, submitting again … and so on.
The solution
Now that we have suffered enough we have also found an easier and much more intuitive way to do those kind of things. Let the user edit the data in place, just there where they are shown. This does of course have other traps, like: how does the user know what is editable, roll the mouse over every item to check? I think that the data that are editable should be obvious by the context. If the user is on one page of his address book, then it should be obvious (by design and context) that the address book data are editable. Additionally the web designer can also mark the elements that are editable. For example showing a border around them, using another color for those elements (we are used to different colors from hovered links) or by slightly animating the editable text.
To make a long story short, here is the example. Just feel free download and use it.
PS: I couldn’t yet figure out how to embed it here in wordpress, someone might help me so I can make wordpress allow me to copy+paste the code in here and leave it untouched. Not even en iframe with a src attribute would work (src becomes xsrc). I guess I gotta invest a bit more in finding that out :-).
Now that it is already a long time ago, that I had not touched openTimeTool I still get nervous when I read about new time trackers emerge. On techcrunch I just read about 14Dayz a new Web2.0 time tracker. It is still in a closed beta, if I properly understood it and I only found one blog with a couple screenshots. Since I got so used to an allow-me-to-be-lazy screencasts I am disappointed when I can’t find one.
I got so many ideas about what to do better in a time tracker, I just don’t get to rewrite the application. OpenTimeTool already had some nice JavaScript helpers like the auto correct function. But I think there is a huge potential in every corner of a time tracker application. If I just think about reports and the new canvas element, about liquid browsing and many other things. That could be quite exciting.
If someone is bored and wants to pay me just for writing a (new) time tracker just contact me (wolfram at kriesing dot de).
I am also available for freelancing of other kinds, currently deeply diving into JavaScript, dojo, AJAX and alikes again.
I just read on the dojo mailing list that “JSEclipse has built in dojo support now“. You can see a pretty neat video on the JSEclipse site. Now I only have to get the plugin running on Mac OS X, last time I tried it just didn’t work (which is a strange thing for a Mac user :-)). But after watching the video I know I will have to dive in and make it running.
This is the first entry in this category: AJAX (style) guide. Here I will try to sum up some of the main concepts that AJAX provides nowadays, as I see them. Most of the things might be really tiny problems and their solution - very easy for copy and paste. So enjoy.
You remember the pain as a programmer that the form submit always took longer than it actually should and mostly longer than the user expected. Some users even clicked on the submit button again, because it seemed that nothing had happened since the last click, even though the form had been submitted, it just needed some time. But the user didn’t know, because we didn’t use JavaScript efficiently enough.
Nowadays it is already a standard to change the submit button’s text right away to something like “Sending…” and disable it. You can even add a little hour-clock icon or something alike beside it. This way the user sees that the form had been submitted, no matter how long it takes, the user won’t press submit again. Because the button is disabled, he can’t. But most important he gets a visaul response that the form is on it’s way, so now he implicitly knows that he only has to wait.
Here is the example, just try it and click the button:
fscklog pointed me to an interesting technique called liquid browsing, I have to say awesome! Just watch the video and you will see how useful that is for browsing categorized data, I can imagine a lot of use cases for it. Wow, I will be watching …
Feedreaders are a nice thing, but still have way of what I want. Actually I want to have feedreader that understands my interests and realizes that, when I have only half read an article that it either marks it as not-interesting or unread (it should be able to find out). I should be able to rate articles and tell other “go away”. May be I would give it a week to learn what I want, but after that I want it to know! Searching through all the articles that had landed on my desk(top) and finding the interesting ones is one of the things that is pretty time consuming.
My current strategy is that I have stripped down the number of blog I subscribed to and I only have one category called “Read always”, which contains about 30 blogs. Mostly those are family related blogs and a couple of those that I am interested in. When I am bored I go into the other categories and read articles there, but that happens like once a week.
Actually I imagined a system that does all that news-reading stuff for me but as audio, so that I can be on my way home and when putting on my headphones it gives me an overview of what news might be interesting for me. With two buttons on my (remote) control I tell it to skip of remember this article (sometimes I just don’t feel like to certain topics, though they are interesting). And after a while this news-reader (which is a real reader!!!) will also have learned, that I don’t want to listen to the difficult technical stuff when I am on my way home really late at night, but that I want some easier topics or even music (though that happens rarely :-)). Let’s keep dreaming …
Finally Safari gets some developer usable tools. The Web inspector introduced a little while ago is still in development but available via the nightly builds. Now I only want a JavaScript console and even better a debugger. I haven’t developed much JavaScript for Safari yet, but if it has no JS console it is a drag. Hopefully the day I have to take on Safari it will :-).
Now that I am playing with google maps for about a week I realize that there are some shortcomings. Here go my simple suggestions, that might seem obvious.
When reloading a map the images don’t seem to be cached, so even after moving around and going back to the same place (on the map) it seems that the pictures need to be reloaded every time. This might be clever in order not to fill up the browser cache, but seems not very fluent.
When zooming in (in little steps) using the zoom control on the map, the image of the previous zoom level is hidden and the new one gets loaded, which is well visible, because you might see nothing for a while.
So why is the picture of the old zoom level not just simply scaled up (which might look ugly for a while, but at least there is something) and later, when the picture of the new zoom level is loaded, replaced by it? I think this would make zooming look so much smoother.
My two cents, so far.
The API documentation that is online unfortunately does not show all the methods that are implemented and doesn’t give too much insight information. I found myself quite often looking into the JS code to understand and find out how things work.
Besides all the ranting I think (google) maps is a great thing, especially to be able to embed it in your application. I suggest go and try it, it’s fun.
a spanish delicacy, created by Mayflower GmbH, the well known Munich-based PHP specialist, will be presented at CeBit these days. Just the logo has something to do with a sausage, Chorizo will show you where your web application is vulnerable.
Initially Chorizo is focused on PHP based applications, which have a big potential of vulnerabilities. Later Mayflower will add support for other languages as well. But the plugin mechanism enables you already now to add your own test cases.
To set up Chorizo you only need to tell your browser to use a proxy and you can start shivering. Chorizo will surely find the security wholes in your application and you will need to work overtime. Go and check it out and make your apps secure!
I was just listening to Clayton Christensen’s, the inventor of the term disruptive technology, speech “Capturing the upside” from the OSBC 2004. When he uses the example of open source tools, which sometimes have less features and might be harder to use and claims this as a disruptive technology my brain started to draw the line to EQing.
But lets go slowly here. What are those two things?
A disruptive technology comes to dominate an existing market by either filling a role in a new market that the older technology could not fill [...] or by successively moving up-market through performance improvements [...].
And EQing is a technology introduced by Kathy Sierra.
An audio equalizer was a natural metaphor for us, and [...] we use the concept of EQing to brainstorm new designs.
Christensen states that open source is a great example for disruptive technology, because it (sometimes) brings products to the market that are crummier. The disruption is not a breakthrough improvement but a redefinition of improvement.
It performed so poorly that it couldn’t be used by customers in the main stream. But it brought to the market a simpler and more affordable product that allowed a whole new population of people to begin owning and using it.
This quote is just something that EQing is projecting very nicely as moving sliders. You just (create and) move the sliders “number of features” and “usability” way down, which results in moving the sliders “price” down (or simply remove it :-)) and “availablity” further up (there might be better names for the sliders). May be I don’t hit the nail exactly on the head. But I hope you know what I mean. Disruptive technologies might come around by just tweaking a set of parameters of existing technologies/products. Somehow the EQing technique is very nice to picture what happens. I might start using it a bit more intensively.
Not to forget that Christensen says later this product at some point also intersects with the main stream.
Please note that I did not try to explain the theories in detail neither I enlightened you on all parts of it. I only pulled out those parts that I think had an interconnection for me at this point in time. The entire theories are much more exhaustive than stated here.
Not everything is great about having a Mac. But the one thing that really drives me crazy is when I hit the wrong key combination, especially when it is Apple+Q instead of Apple+W.
Apple+W is for closing a window, such as in my editor, Firefox, Safari or whatever application.
Apple+Q, which laying right beside it (!!!) is for quitting the entire application.
It is just very sad when I close the entire application though I only wanted to close a window of it.
I was just listening to the PodCastof Steffen Meschkat from the Carson Workshops Future of Web Apps Summit. Partly interesting, he is mainly talking about the technologies used for modern web apps, JavaScript, CSS, DOM, etc. and ranting about the unmaturity of the specs and implementations. Besides mentioning the common problems, he also talks about half-loaded pages being accessed for DOM manipulation and the poor separation of the actual browser application and the page execution. Eventually someone is mentioning that JSON is nothing new, it’s just the JavaScript literal syntax.
It’s worth listening!
What I found especially interesting was that he mentions that JavaScript lacks transaction based rendering, means manipulate the DOM in various places and “commit” the changes at once, which allows for perfect visual control e.g. for animations (Flash has that due to frames).
I was heavily nodding when he was talking about semicolon insertion. You can write JavaScript either with a semicolon at the end of the line or you can also leave it out. But I don’t really see it as such a problem, just put an ending semicolon everywhere. And don’t make the lines too long, especially when you generate them, the IE doesn’t like that much, I remember.
Now I am working day in day out with dojo, finally I got myself to working with it.
Dojo is the Open Source JavaScript toolkit that helps you build serious applications in less time. It fills in the gaps where JavaScript and browsers don’t go quite far enough, and gives you powerful, portable, lightweight, and tested tools for constructing dynamic interfaces. Dojo lets you prototype interactive widgets quickly, animate transitions, and build Ajax requests with the most powerful and easiest to use abstractions available.
Well, the first day I took all this for real and hoped to build applications in less time using the powerful, portable, lightweight, and tested tools. I’ve learned two things: 1) don’t believe everything and 2) head up. Read the rest of this entry »
