Posted
Tue, 08 Apr 2008 22:28:01 GMT
to Posted in Programming, Ideas
Tags app engine, deployment, development, google, integration
Today Google announced Google App Engine, a free (within certain limits) deployment environment in which people can develop, deploy and host web apps. Currently, the offering is for python only, and you are kind of tied to Google’s data store, but in return you don’t have to worry about server management, infrastructure, or paying money. Additionally, they have a pre-packaged SDK to give developers an identical development sandbox, as well as a method to deploy local code to the production environment.
However, I think they missed a way to make it even MORE awesome. Imagine, if you will, that they had integrated this package with Google Code. Suddenly, developers have an entire managed development and deploy framework. Develop on your workstation with an environment that is identical to the production environment, check in code so that it is managed, have a web interface that manages deployment from the repository so that you could deploy specific revisions/branches to either a staging area for testing or the production environment, with easy rollbacks if a problem is noticed…... since one of App Engine’s goals appears to be to lower the total cost of entry into the app development world, this just seems like it would make sense and work so well.
no comments | no trackbacks
Posted
Tue, 06 Mar 2007 14:02:32 GMT
to Posted in Programming
Tags freebsd, gems, ruby
The server I happen to host some of my stuff (ie. this site) happens to be running FreeBSD. In most cases, this doesn’t cause any problems. However, in the case of installing certain ruby gems, I would get an error when compiling native extensions. In particular, with the fastthread gem (I was trying to upgrade Mongrel), I received the output:
make install
/usr/bin/install -c -o root -g wheel -m 0755 fastthread.so /home/ssmith/gems/gems/fastthread-0.6.4.1/lib
install: /home/ssmith/gems/gems/fastthread-0.6.4.1/lib/fastthread.so: chown/chgrp: Operation not permitted
I received a similar error a while back when trying to install mongrel, and at the time I had asked one of the friendly admins to just install it as root. However, I like installing my gems locally, so they are easy to update, and this was preventing that. Additionally, I wasn’t experiencing this on another machine running Debian, so what was going on?
Some investigation showed that on Debian, install wasn’t being told to change the owner and group, while for some reason it was on the FreeBSD machine. So where was this being set?
Turns out that rbconfig.rb, a part of the actual Ruby distribution, was the culprit. A collection of configuration variables for Ruby, it had the following line:
CONFIG["INSTALL"] = '/usr/bin/install -c -o root -g wheel'
while on Debian we only had:
CONFIG["INSTALL"] = '/usr/bin/install -c'
Apparently, the FreeBSD Ruby port sets things a little bit differently, which causes pain for local installation of gems. I’ve currently had the problem fixed by having that line set to the same values as Debian. However, as that file is automatically generated each time Ruby is updated, hopefully the root issue will be fixed in the next version for FreeBSD.
no comments | no trackbacks
Posted
Thu, 28 Sep 2006 17:33:35 GMT
to Posted in Programming, Projects
Tags hCalendar, hCard, iCalendar, microformats, tigerevents
The other day, I came across this Microformat Bookmarklet, designed to extract hcard and hCalendar markup from a website and into a format that people can use. ‘Hey’, I though, ‘that’s pretty cool, why don’t I use those in places’.
It was the motivator that finally got me to fix a long open feature request for TigerEvents. Now, the event view has hCalendar markup for those who care.
Once that was done, I thought, since I had already done hCal, why not figure out iCal export? Easier than I would have thought, thanks to the iCalendar gem and the send_data method. Now people can grab iCalender export by individual event, group, or category. People should even be able to subscribe to iCal files and have events automatically shown in their calendar app (if said app has this feature). Only future events are shown, however, in order to cut down on file size.
Finally, while I was working on the above, a friend stopped by, saw what I was doing and commented, ‘you know… it would be awesome if I could click on a link and have the event loaded into my google calendar’. So, quickly scouring the web came up with Google Calendar event publishing guide and after a few minutes, I managed to add that functionality as well.
Now for RSS feeds…
no comments | no trackbacks
Posted
Sat, 16 Sep 2006 13:49:41 GMT
to Posted in Programming
Tags rake, ruby
Many of you may know of my love for the Ruby language. Used for most of my own projects and quick scripts, but have never been able to use it in any of my paid work. Until now.
It started a few weeks ago with a script I wanted to write. As I am the ‘translator guy’ at work, from time to time I need to convert the XML files that store the English text to something that a non-technical translator can easily read (I thought the XML was readable, but apparently I need to hand over Excel spreadsheets). As Ruby has nice XML library included, I just quickly whipped something up, and away I went. Never intending this to be anything more than a tool for myself and knowing my boss wouldn’t care as long as it got done without me having to spend a few hours, it seemed like the thing to do at the time.
Fast forward another two weeks. I overheard a few of my coworkers talking about how they can’t manipulate XML files in Auto-it, which they were using to cover some deficiencies in another build tool we were using called FinalBuilder. They started talking about either writing their own XML parser, or using yet another tool/language to do what they wanted.
Read more...
1 comment | no trackbacks
Posted
Sat, 16 Sep 2006 13:45:27 GMT
to Posted in Programming
Tags railsday, ruby
So yesterday was RailsDay2006. The objective: Write an entire web app of your choosing (with some restrictions) in a span of 24 hours.
Oliver and I decided to participate together. I came up with a bunch of ideas, but we ended up doing something Oliver had in mind. The goal: a deli.cio.us clone that we called Tasti.er. We wanted a simple interface, where everything happens on one screen. We put it together in under 18 hours (with the final commit happening just as the competition closed).
Check out our performance log or Oliver’s RailsDay Post.
no comments | no trackbacks
Posted
Tue, 28 Feb 2006 00:06:56 GMT
to Posted in Geek, Programming
So, lately I have been spending some late nights on campus. I mean LATE nights, 1….. 2….. almost 3 in the morning. Have I been spending late nights working on my schoolwork? Ok, you can stop laughing now. No, instead I have been doing some hardware/software hacking with a Roomba. My friend Oliver and I have been busy putting the Roomba together and doing cool stuff with it. Ok, ok, Oliver did most of the hardware work, I just provided ideas and suggestions along the way. End result: A Roomba being controlled using a USB Gamepad over the wireless network in the Computer Science building. Over the break, several individuals from tech support came to take a look at it cause it sounded cool, and we even showed it off to the high school students that showed up at the Open House last Saturday (they also thought it was cool. Right now, we have the movement controlled via one of the analog sticks, though we have a lot of cool ideas (which I am sure I will write about as they are accomplished).
More information (as well as pictures) can be found at Oliver’s site here
Additionally, Make Magazine has already featured it in their Make Blog. How cool is that?
no comments | no trackbacks
Posted
Wed, 23 Nov 2005 17:12:24 GMT
to Posted in Programming
Tags migrations, rails, ruby
As I recently said, I switched TigerEvents over from using a MySQL input file to migrations. There were many decisions behind this choice.
- I wanted the code to be database neutral. Using migrations would allow me to automatically support MySQL, PostgreSQL, and SQLite by making changes to one file instead of 3.
- I know that the database for TigerEvents is going to change at some point in the near future. Rather than write multiple upgrade scripts manually, I could just use the built in migration functions to do it better.
- If for some reason I make a mistake and problems occur on the production site, it is easier to roll back to a previous version using migrations than dump the database, roll back the code, reload the database, etc. (Note, we still make sure to back up the database, cause not doing that is just tempting fate)
- Migrations will, in theory, make development easier. Someone made a change to the schema? Just run rake migrate, and your database is automatically updated. I think this is easier than reinitializing a database and then loading it with data repeatedly (though the second part of this can be handled with Fixtures).
Read more...
11 comments | no trackbacks
Posted
Thu, 03 Nov 2005 18:44:40 GMT
to Posted in Programming, Projects
Tags rails, refactoring, ruby, usability
Today is World Usability Day. A day to work towards better user experiences in products and experiences. I also decided to use this day as a deadline for the next release of TigerEvents, one of the software packages I work on. 39 closed issues later…............... a brand new release. All that remains is to migrate my.dsu.ca to a new server, upgrade to the new version, and then all users can revel in…..... well….... errr…....... actually, I must admit there isn’t anything major in a regular user’s perspective.
Removing that pesky sidebar proved troublesome (due to Javascripting and CSS issues), and is unfortunatly pushed back (I’m working on it!). You will see that events actually have their formatting preserved, so no more giant block paragraph that is a pain in the ass to read. There are also some more subtle rearrangements and additions to some options, which I think will make posting events easier for people. Admins get a little more, mostly avoiding huge lists of groups and users when trying to navigate (pagination helper is your friend).
And the backend stuff is where most of the changes occured. I personally refactored the code so that the authentication stuff is easier to drop into other code (important since we want to use it in multiple projects. Additionally, I refactored the code to make the entire system database neutral, and to have as much as possible done through ruby. This includes important things such as setup and schema migration. This was the longest and largest changeset I have done in a while, and I am glad it is over. Of course, I need to pass this on to several budding developers so they don’t make the same mistakes, so…....... check back at some point in the future.
What however, is the future of this project? The individuals working on it (and by that I mean myself and Oliver) have decided we want to refocus on putting the ‘my’ into the ‘my.dsu’. Upcoming, expect to see new skins, a better actual interface devoid of those confusing multiple columns, and other things that will help the USER kick ass. So think of this World Usability Day not as a day for which we bring out a ton of usability fixes, but a day where we begin to devote more attention to where it is needed.
You know, after we take a much needed break.
1 comment | no trackbacks
Posted
Fri, 07 Oct 2005 10:42:09 GMT
to Posted in Programming, Projects
Tags rails, ruby, tigerevents
Finally, after long hours, little sleep, and lots of work, the 0.5.0 release of TigerEvents, code named “It’s Finally Our So I Can Take A Break” was released the other day on both Sourceforge and Rubyforge.
The focus of this release was getting all the proper administration interface stuff working properly (sorry front end only users) and trying to document it enough so a person can take the code, set it up, and run it on another machine.
Now that the initial file release is out, all I have to do is upgrade my.dsu.ca (merging is going to be a pain in the ass), work on 0.6.0 (which involves merging my development branch back into the trunk, ugh), and redo that ugly, ugly interface.
Regarding the interface, I plan to do something even more minimalistic than some people’s ideas (the one’s I am getting are awesome though, don’t stop). It will, at the very least, grant more open space, as opposed to cramming everything important into a small area. A primary advantage of starting out small is that it will be simple (except for all the XMLHTTPRequest stuff I need to do), and if people want more, I just add more, instead of scalling back and forth.
Oh, and I will do my best to get rid of that blinking text box.
1 comment | no trackbacks
Posted
Tue, 04 Oct 2005 19:16:23 GMT
to Posted in Geek, Programming, Projects, Work
Tags rails, ruby, tigerevents
As already mentioned I have been working on a project called TigerEvents, which powers the my.dsu.ca website.
This project, written entirely in Ruby On Rails, took 4 part time students 2 months to code a working, publicably usable beta. Pretty sweet, since some of us had other, paying, supposedly full time jobs on the go as well, and all of us had other responsibilities.
The my.dsu.ca website has gotten 102430 requests since Aug 25. Not bad I suppose, but I think we can do better than that.
The main problems? I know it, you know, it’s the visual layout. Sure it sucks. A layout like this is when a graphical artist that is supposed to do work totally flakes out and techies are left in charge. Also high up on that list is usability. Some things work well, some things…...... not so well (hey, it’s beta). So how do we fix this? Well…..... I am hoping that you, the public, the intended audience, the actual, non-involved USERS could give me a hand here. Let me know what you like, let me know what you don’t like, let me know what YOU would like to see.
Go ahead, chew me out, rip it to shreds, praise it, stomp it, love it, hate it. Just give me something I can use.
2 comments | no trackbacks
