9:29 AM EST Wednesday, December 31 2008
If you haven't heard the news already, BrowserMedia will be releasing BrowserCMS as an open source product, based on Rails! BrowserCMS 2.0 is a proprietary J2EE product and we've been working on BrowserCMS 3.0, a Rails-based version of the product for the last few months. Patrick Peak and I will be giving a few presentations in the next few months covering some of the motivations and lessons learned, as well as previewing some of the features of the product. First up will be the DC Ruby Users Group on Thursday, January 8th at 7:00pm. After that, we'll be up in Baltimore for B'More on Rails on Tuesday, January 13th at 7:00pm. Then we're headed to Orlando, Florida for Acts As Conference on Saturday, February 7th at 10:00am.
BrowserCMS 3.0 isn't just an Open Source Rails version of BrowserCMS 2.0, it also has a new design and lots of new features. We will be finishing up the initial development phase next month and will release the initial beta version at Acts As Conference. We'll be building out sites with BrowserCMS 3.0 for our customers at that time, so we'll be looking for people in the community to try it out and give us feedback.
We're excited about what we'll be able to do by bringing together BrowserCMS and Rails. We're also looking forward to Rails 3.0 and taking advantage of new features in Rails brought on by the Rails/Merb merger. So if you have a chance, please stop by one of the upcoming presentations, see what we're up to and let us know what you think.
Posted in
Technology |
Tags
Rails, BrowserCMS |
0 Comments
6:23 PM EST Monday, December 29 2008
Do you have an app you want to keep in version control, put you don't want to put it on Github? Well, you can obviously use git to keep track of your versions, but do you want some way to back it up? Do you have a server you plan to deploy the app to already setup with SSH keys and everything? Assuming you already have git installed on both your machine and the remote machine, here's all you need to do:
Create The Remote Git Repo
$ ssh yourusername@yourserver.com
$ mkdir yourproject.git
$ cd yourproject.git
$ git --bare init
Create The Local Git Repo, If You Haven't Already
$ git init
$ git add .
$ git commit -a "Initial Checkin"
Add The Remote Repo
$ git remote add origin yourusername@yourserver.com:yourproject.git
Push To the Remote Repo
$ git push origin master
Now you have a full copy of the repo locally and on the server.
Posted in
Technology |
Tags
Git |
2 Comments
12:00 PM EST Tuesday, December 23 2008
Lately on my commute back and for to the Bethesda from Baltimore I've been listening to the Stack Overflow podcast. It is hosted by Jeff Atwood and Joel Spolsky. They've had a lot of great guests lately, like Steve Yegge and they also have a lot of good conversations about software development in general. One thing I like about listening to this guys is that they are C#, ASP.NET, Visual Studio Microsofties, which is the complete polar opposite community of the Ruby community. What technology podcasts are you listening too?
Posted in
Technology |
Tags
Podcasts |
3 Comments
2:22 PM EST Sunday, December 21 2008
In this year's NFL season, kickers are 1024 out of 1029, 99.5% on extra points. I bet if you looked at those 5 misses, they are the cause of a botched snap/hold or blocked. The fact that is that extra points are a mere formality, a foregone conclusion.
Imagine if in the NBA, each team had a designated free throw shooter. Every time your team had to shoot free throws, you bring in the free throw specialist. Every NBA team would have some guy like Ted St. Martin, who once, at the age of 60, made 5,221 free throws in a row. This player, at the age of 60, is obviously completely incapable of playing on the team for a normal play, because we lacks the athleticism to compete against other players, which is why the rules of basketball don't allow for a designated free throw shooter. The player who gets fouled must shoot the free throw. If instead you have a designated free throw shooter, who is a 99.5% free throw shooter, shoot all free throws, there is no drama, it's just a boring foregone conclusion.
So instead of having allowing the place kicker to kick all extra points in the NFL, imagine if the player who scored the touchdown had to kick the extra point. If the player who scored is injured or completely incapable of making an extra point, then you have to go for two. Each team would still have a kicker for field goals, because 40 and 50 yard field goals are much harder. The fact is that kicking an extra point is not that hard, so having all players have to kick extra points would add to the drama, as well as the comedy. Imagine an a defensive tackle who scoops up a fumble and runs it in for a touchdown trying to kick an extra point.
If you love this idea, link to this article on facebook, delicious, your blog, whatever, let's wee if we can get this into the mainstream media and who knows, maybe the NFL would even consider it. At least it will be fun to argue about.
Posted in
Sports |
Tags
NFL |
5 Comments
11:42 PM EST Friday, December 19 2008
One of the many "fringe" languages that has been on my radar for some time now is Haskell. Haskell has what looks to be a pretty good book available online and a local book club forming, which presents a great opportunity to study it. What is interesting to me about Haskell is that it is a statically-typed language, like Java, not a dynamically-typed language like Lisp, Ruby, Python, JavaScript, etc. I have really become fond of dynamic typing while programming in Ruby, but I always like studying languages that challenge your fundamental beliefs about programming.
Incidentally, this is one of the reasons I have been really interested in Clojure. It challenges the validity of object-oriented project in a very serious way. In Clojure, you don't define new classes, instead your program is simply comprised of functions that takes input, possibly call other functions, and return values. Studying functional languages helps you to see the benefits and weaknesses of object-oriented programming. Read more about this idea of studying programming in Glenn Vanderburg's article about Koans.
So anyway, back to Haskell, and the paradigm here that is worth studying is static typing versus dynamic typing. I must admit, after moving from Java (a statically-typed language) to Ruby (a dynamically-typed language), I'm currently a big fan of dynamically-typed languages. So I'm trying to keep an open mind in studying this, but this passage from Chapter 2 of Real World Haskell I have to object to:
Programs written in dynamically typed languages require large suites of tests to give some assurance that simple type errors cannot occur. Test suites cannot offer complete coverage: some common tasks, such as refactoring a program to make it more modular, can introduce new type errors that a test suite may not expose.
In Haskell, the compiler proves the absence of type errors for us: a Haskell program that compiles will not suffer from type errors when it runs. Refactoring is usually a matter of moving code around, then recompiling and tidying up a few times until the compiler gives us the "all clear".
One thing I learned when moving from Java to Ruby is that developers often rely on the compiler as a false sense of security. The notion that you can refactor a bunch of code, get it to the point where it compiles and then feel that your code works is dangerous. You code can still contain all sorts of runtime and logic errors, therefore if you want to have any degree of certainty that your code is free of bugs, you need to have some sort of test suite, regardless of if you are using a dynamic and statically typed language.
I've also heard the argument made that statically-typed languages allow you to write less tests, but I have also not found this to be the case. Most syntax and type errors will be found with the same tests you use to test the logic of the program. In other words, you don't have to write one suite of tests to check for syntax errors, one for type checking and another for testing the logic of your program.
So the moral of the story is that regardless of whether you are writing your code in a statically or dynamically typed language, you still have to TATFT.
Posted in
Technology |
Tags
Haskell, Testing, Clojure, DynamicTyping, Ruby, StaticTyping, Java |
6 Comments
