we were looking to buy a car and rather than dumping the results in the recycle-bin here they are for the web-crawlers:
* trip calculations are based on a 102m trip to SJ and back with gallon price at $4.3
Author Archives: ohad
Playing with Yahoo Pipes
So I was sitting this Sunday afternoon, getting pissed that there’s no easy way to monitor replies on Twitter. I talk with people there and there’s no serious built-in feature in Twitter that will notify me when people reply to me, which, other than direct messages, is exactly when I want to jump back in and continue the conversation.
I ended up taking the RSS for my updates – http://twitter.com/statuses/replies.rss (requires your credentials), pulling it through Yahoo Pipes (because its able to supply my credentials to Twitter), and using the result of that pipe with Pingie (a useful free service that does RSS to SMS). Why not Yahoo Alerts? It just didn’t work…
A few tests later and I get an SMS whenever someone replies to me on Twitter.
Now, who can stop there? just what I thought.
I have this stock which is suppose to fluctuate coming Monday/Tuesday, I’d like to have something automatic notify me when that fluctuation takes place. An hour later I’m done with my first “serious” Pipe – the Stock Alert:
It was fun to write because it forced me to learn the whole Pipes thing, and I’m happy to add that to my arsenal of ‘quick and dirty’ utilities, maybe even not that dirty. The idea is to generate a new RSS item any time the alert pops, so right now it achieves that by reiwiring the date and time into both the item’s guid and its pubDate.
Open issues:
- What happens after 1 alert is generated and sent? right now a shitload more will keep on coming. If Pipes lets you store variables between executions this could help.
I have another pipe that does a Union bewtween my Twitter replies, the stock alert and whatever I come up with next. This endgame Pipe is what gets SMS’d whenever it changes.
My concusion: Pipes is very cool and more than cool its very powerful and useful. Works great as a Sunday afternoon game.
IM protocols, do they support dynamic embedded images?
here’s a scenario i’d like to have:
- i’m chatting with someone on IM
- i want to show him something i’m seeing on my screen
- i hit ctrl+apple+shift+whatever, get an overlay control to crop some part of my screen
- click my mouse, boom that part gets cropped and sent to my chat partner
- my chat partner gets a small message embedded into his chat dialog saying an image is being transferred with a progress bar
- when the image is transferred its shown as an inline thumbnail within the chat where the original message for ‘image being received’ was shown, this is chronological
- single-clicking the thumbnail brings up the entire image in a thin embedded viewer, no external stuff
- there’s a button to ‘save to file’
i know i can screen-capture myself, save to a file, send to my friend, he accepts it, saves it to his hard drive and opens it with his default image viewer (which may be photoshop, OUCH). but we all know this flow sucks and that’s why we don’t do it.
what’s needed?
- IM protocol support for dynamic inline images (i think MSN has something like this, others?) this should enable injecting an image into the chat and later changing it. the whole process (image being sent, progress) can be done using solely with images.
- IM client support for capturing/cropping the screen and hiding the details from a the user while the data is being sent to his chat partner.
any ideas? if MSN supports enough of this in the protocol I vouch to get someone to write client support for this in Adium and maybe pidgin on windows.
Multi-Core Software
It’s a known fact that CPU cores are not going to see high increases in their singular power. The alternative chip-makers have come up with is multi-core – the poor man’s SMP. It seems like future CPUs will be trying to maintain Moore’s law using more cores rather than more singular power.
Does this change the game? does it pose an opportunity?
It certainly forces hard-core programmers to focus on parallel-ability. Most programmers don’t deal with stuff that needs to be optimized (writing on_click handlers for buttons anybody?) but the core that writes our OSs‘, implements STL for us, writes graphic drivers, and the algorithmic type will have to keep up on their multi-threading skills.
The more popular programming languages have done a good job of not introducing multi-threaded concepts into their language structure. I say good because it has been generally unnecessary until now. What happens though if our PCs are suddenly all multi-core by definition? Do we expose this in high-level languages such as C#?
I wonder if we can reuse ideas from the distributed computing move of the past 10 years. I remember how in ’98 I was thinking about the potential growth of distributed computing and how this growing field lacked tools to write parallel-able code…
Youtube Bucket testing?
