Yes that is a dual meaning. I was reading this blog about text editors. The truth is that I am an editor slut. I use different editors for the different things that I need them for. I am not just a one trick pony nor am I one language coder or a one editor kinda guy.
Eclipse is my Java editor. I would use something less bloated but the Java code I develop in have extremely awesome integrations into Eclipse. Android apps that I develop are so much easier to develop, test and deploy using eclipse. I can deploy straight to my phone plugged into the USB port which is just such a time saver. I have become a big fan of GWT because of its performance for the end user. Not to mention it works fast and great on mobile browsers. GWT is much faster to develop using Eclipse just be saving the file and refreshing the browser.
WingIDE I just started trying out since PyCon. I am feeling kind a hooked for hacking hard core in Python. I was using Komodo Edit which also had good Javascript support but it is way lacking in Python support. The downside being I am going to have to pay for WingIDE and I don't think I can afford the professional version but it is probably worth it since I spend like 6 hours a day hacking Python.
Emacs I use for basically commit messages but I am thinking I might use it entirely instead of TextMate which I purchase years back and it is nice but not all that for making my editing life easier.
Since I wear many hats as a developer entrepreneur then I need to use whatever is the most productive tool.
Monday, February 22, 2010
Code tools
Labels:
java,
javascript,
python
PyCon 2010 was awesome!
This years PyCon 2010 was pretty much awesome! Really enjoyed the entire experience. My favorite talk was the last keynote Antonio Rodriguez the slides are online but I could not find the video yet. I enjoyed the async non-blocking talk by Peter A Portante. I took the time out to speak with him about it more and he pointed out that we need better access to kernel non-blocking to create a standard Python API that would be uber fast. I agree that is long term goal I am just focused on advocacy right now. Mark Ramm is one of my favorites folks out there. He is a real hands dirty funny kind of person. We discussed NoSQL which was mostly him teaching me stuff about his actual deployment and us agreeing on everything else. Right now I am leading NoSQL as time savings not so much as performance because I think people don't realize the are getting shafted by the performance issues with RDBMS. Anyway I tried to push Riak on Mark by sending him and email and pointing out a bug on his blog (I am sure that didn't help). I am planning on going again next year! Excited that I am going to go to Google IO also this year :)
Labels:
python
Monday, February 15, 2010
Walkscore Widget: my first Android Application in the Market
Sunday February 14 my Valentine to the Android community was free software! One of my favorite sites is walkscore.com and they have ported it to the iPhone. Well I have an a G1 which runs Android. They do not have there entire API accessible just the score. So I create an Android widget instead of a full map application like they have on the iPhone.
Android Widgets are applications that can run the desktop of the phone. Popular ones are Facebook feed, Pandora and stuff like that. They are a bit challenging because they need to be optimized to minimize utilization because of battery issues and stuff like that.
There are basically two actionable items. The first is the green dot and the logo will get the phones current GPS location and update the score on the right hand side. The second is the score which if tapped will open to walkscore websites full page. The website page is a bit slow but it is functional.
The walkscore API was easy to use the tricky parts have been the widget lifecycle and making sure not to use to much battery. There seems to be bugs I am bumping into a lot over the last 18 hours but I have made a couple updates but that is somewhat expected.

During the time that the GPS and score are being retrieved then the display changes to a retrieving icons. This lets the user know that the application is working. For a while I was thinking about doing an autoupdate. First the battery usage is a bit excessive. Second this isn't that useful because the user will need to be looking at the phone and a majority of the time the user will not even have there phone on. Finally I have a limited quota to how many walking scores I can do in a day and the autoupdate one phone could consume almost all of them.
If you have an Android phone and can do me a favor and test it out that would be great just search for "walkscore" in the Market and it should come up. Hopefully I will eventually get access to the full API and can build a cool mapping layered one.
Off to work on my next app.
Android Widgets are applications that can run the desktop of the phone. Popular ones are Facebook feed, Pandora and stuff like that. They are a bit challenging because they need to be optimized to minimize utilization because of battery issues and stuff like that.
There are basically two actionable items. The first is the green dot and the logo will get the phones current GPS location and update the score on the right hand side. The second is the score which if tapped will open to walkscore websites full page. The website page is a bit slow but it is functional.
The walkscore API was easy to use the tricky parts have been the widget lifecycle and making sure not to use to much battery. There seems to be bugs I am bumping into a lot over the last 18 hours but I have made a couple updates but that is somewhat expected.

During the time that the GPS and score are being retrieved then the display changes to a retrieving icons. This lets the user know that the application is working. For a while I was thinking about doing an autoupdate. First the battery usage is a bit excessive. Second this isn't that useful because the user will need to be looking at the phone and a majority of the time the user will not even have there phone on. Finally I have a limited quota to how many walking scores I can do in a day and the autoupdate one phone could consume almost all of them.
If you have an Android phone and can do me a favor and test it out that would be great just search for "walkscore" in the Market and it should come up. Hopefully I will eventually get access to the full API and can build a cool mapping layered one.
Off to work on my next app.
Labels:
android
Friday, February 12, 2010
These are a few of my favorite things..
GWT + Tornado Web + Riak = hackingthought.com
Why?
Why?
- The high performance of frontend combined with high performance backend make for an awesome user experience.
- Non-blocking web servers are just cool! Actual I have blogged about this a lot but it really comes down to efficient resource utilization and simplified programming model.
- Scalable data storage system. This I have also blogged about how RDBMS are quickly flawed for scaling even a small volume of web traffic.
- As these are my favorite tools that I call myself an "expert" (and expect to get paid to consult for them) I should put them together to see what the issues are.
GWT
I wrote up my opinions on javascript frameworks before. For a project where I am choosing the tools I am going to pick whatever creates the best user experience. As the web has provided a lot of platform independent development at the end of the day there are a lot of compromises we must make.
The current GWT compiles Java to Javascript (bytecode if you will) for 6 different browsers. The performance is noticeable not only at load time but using the application. The major down side I can see if there is a bug in the compiled version it could be very difficult to find.
Tornado Web
I wrote a non-blocking web server and I am not even using it (shame shame shame). The truth is I was looking to try and us a non-blocking (async) library for Python and I found it here. The code better utilizes the operating systems non-blocking apis like epoll on Linux and kqueue on BSD. The problem is that I quickly figured out the code base was just so much better than what I was had. The only real problem is that they didn't support some of the features and WSGI in a way that I would have liked. I will probably create a little project to do this but that is for another blog. I already have made some improvements in my clone. So not only do that have a simple non-blocking API for the servers side but they have a good one for using as a client (will talk about this later).
Riak
So I have covered how I think RDBMS that have any amount of traffic fail to provide constancy and force developers into writing lots of performance code. Any content management system more than likely is going to need to scale for large volumes of data and large volumes of traffic. Riak rules! They just release 0.8 which included a Javascript map/reduce plugin for writing map reduce. I actually didn't need to use the map/reduce but for the future features I plan on having I will soon. The main bottleneck I have is that there is no non-blocking Python API for Riak. I plan to use Tornado http non-blocking client to create a Riak client during PyCon ATL 2010 (If anyone can join me on a sprint let me know). This will allow this platform to scale up quickly.
In summary I am very excited about this stack. It really feels like a best of bread tools for creating a rich user experience that can scale for the masses (once non-blocking Riak client is fixed). Please kick the tires and report bugs hackingthought.com.
Labels:
javascript,
nonblocking,
nosql,
riak
Subscribe to:
Posts (Atom)

