I have about a dozen grand projects tumbling about my cranium at any given moment. The most important involve taking my love of computers and programming, and turning it into profit so that one day, when I am rich, I can feed homeless people all the time. One idea that has been bubbling on the biggest back burner has been to make myself marketable as a website designer/online application developer. To do this, I have studied several approaches, and am near making something useful. First, you must have a system to develop upon, and a system to receive the code. I am of the opinion that the two should match, if not the exact hardware, then most certainly OS/application versions, file versions, etc. I see the wisdom in this approach because at work we have two systems running basically the same thing. One is MS SQL Server 2000, the other is MS SQL Server 2005. Both machines have a 'dev', 'test', and 'production' instance, and the process we use for promoting changes in the system is different for each machine. People, this is a product made by the same company! It's kinda scary to me to think that there are vastly different ways of doing thing just in the different versions of the same software.
Granted, FOSS *nix operating systems and software is a little different, grep is grep and vim is vim (and awexome, suck that EMACS boys!) no matter the *nix, but there are some differences. Take for instance the Ubuntu version of shutdown and the FreeBSD version of shutdown, they both can shutdown the computer, but in Ubuntu it's `shutdown -h now`, and in FreeBSD it's `shutdown -p now`. The difference is huge! in FreeBSD `shutdown -h now` will only halt the system, in ubuntu it powers down. So what's a boy to do? remember two different shutdown commands? maybe, so what if I do?
Personally, as I get older, I am finding it easier to just use one system for developing, and one system to deploy. It's hard for me to invest in learning a gobjillion ways of doing something, so TIMTOWDI is great when gettin' my hack on, but horrible when actually deploying an application.
sigh.
I am rambling to say this, php is not for me I think. I am sure I will be learning more of it, and will be using it from time to time, but I will not find it enjoyable. I love ruby too much. It's exactly what I want and expect in a scripting/programming language. My LAMP cannot be a LAMP, I need something else, another acronym:
FLPR
FLPR stands for FreeBSD, Lighttpd, PostgreSQL, Ruby(or Rails), and it is going to be my deployment platform. I am not sure exactly what I will be deploying yet, Antlers perhaps? but one day, I will be deploying something. I have two obstacles to overcome,
1. Ubuntu has made me OS lazy. I don't know as much as I should about Linux. I've been using it almost exclusively for the past four years, and I used it for two year (way back in the day!) in highschool. Ubuntu does a lot of things for me, so I have been focusing on developing my skills as a generic programmer instead of a competent sys admin. It's only natural right? I abhor specialization though. sigh, that's a different matter.
2. I don't know a thing about lighttpd. It's going to have a learning curve. It's going to be a while before I have to worry about it as I develop my first application, but that brings up another problem. I want to use it because I keep asking myself Can rails scale? and figure even if it does happen to scale very nicely, I still want a fast webserver, the hardware on my deployment machine ain't exactly state o' the art.
the hard target here is the FreeBSD way of doing things. Currently, I utilize the most recent ruby, the most recent rails, and I use rubygems to manage my gems. That is not the FreeBSD way. I am not even sure how to do things my way on a FreeBSD platform. Should that be a clue? Why not just use Linux? Simplest answer to that is "because I don't want to" :P It is honestly, a little more complicated than that, but that would be a political discussion, and it would also be an adventure in missing the point. here are some issues I have had with FreeBSD recently (6 months to a year ago)
1. FreeBSD uses ports to install gems, and perhaps my google-fu needs practice, but I haven't been able to discover a good way to use rubygems to install gems in FreeBSD instead of the ports. Gems need to be installed via gems, not via ports. I cannot compromise there.
2. Related to item 1: ruby on FreeBSD is old. I think I can fix that, at least I will be able to, or maybe I can get a friend to look at it for me, and guide us on the way.
Once these two issues are sorted out, i will begin developing an awesome application. until then, I languish along.
l8rz.
2 comments:
Well, you know where I stand on this as far as the underlying operating system goes -- FreeBSD FTW! -- but what's best for me isn't necessarily best for you. When you aren't getting your hack on and you are seriously thinking about a money-making venture, you need to spend more time on your money-making app than on the OS administration. If you are equally comfortable with administration of Ubuntu and FreeBSD then we can move on.
If we leave acronyms aside and choose the tools best for the job (and that you already know, for extra points), then you can kill the lighttpd hurdle by sticking with Apache. Likewise for MySQL vs. PostgreSQL. If there is some compelling feature of an unknown tool that makes learning said tool worth the effort then by all means do it, else sticking with a capable tool you already know allows you to (again) focus on your app dev.
Now the hard part -- Ruby, and specifically Gems. You already know how the FreeBSD ports system works and you have a need (or just desire?) to build your app using the latest available tools which aren't yet in the ports tree. Your options here are to either...
(1) Develop on the versions of Ruby/Rails/Gems in the ports tree, forsaking the latest available features for the stability of mature code (which ironically is kind of what FreeBSD vs. LINUX boils down to (licensing wars aside)). Can you dev your app on what's available in ports?
(2) Completely ignore the ports tree and build your Ruby (and friends) from their respective project sources and keep track of the library & other dependencies manually (this takes away from money-making app dev time!)
(3) Team up with the Ruby (and friends) ports' maintainer(s) and assist them in keeping the ports up-to-date and perhaps also collaborate on a better way to manage Gems. It's possible that the ports' maintainers will have a really good answer for why the Gems are managed the way that they are in ports, else you can put forth a good argument for change. Again, this takes away from app dev time.
If you have the time it takes then option #3 would be the most valuable to you and the wider FreeBSD ports user community, otherwise #1 is the best option. Since #2 would require as much time investment as #3, not to mention that you would be bearing this burden alone, I would only consider this in the absolute worst case scenario. So, what killer feature does the latest Ruby have that the FreeBSD port doesn't? Take the answer(s) so that question and honestly label 'need' or 'want' next to each one within the context of what's required to build your app (not what you require to hack and be on the knife's edge for the sake of fun).
All of the above is written as if your ease of OS administration is equal between FreeBSD and LINUX. If these two values are not equal then you need to start at the OS level and build up with what you know. Like I said, this is all about maximizing the time you spend developing the app that will put food on your table and keep your servers running.
One final thought is about licensing. I don't know the nature of what you are developing and whether the differences between the licensing schemes for the two operating systems would impact your app, so this may be a non-issue. Just keep in mind how free and unencumbered the BSD license is compared to everything else.
I am sure we will be discussing this more in the coming weeks and months.
I'm with you as far as the philosophy of not worrying about os admin while programming. That's one reason why I've concentrated so hard on Ubuntu. I also want to make sure that I can do some sysadmin type stuff though, I believe both of us can agree that specialization is for insects. The point of developing and deploying in the same environment is a design and security choice.
I know what you mean about using the best tool, I have political reasons for not using MySQL, they are in jeopardy, http://bit.ly/cJgKIo for a year old optimistic take on it. Oracle is not trustworthy. Apache vs Lighttpd is not such a big deal, Lighttpd will run on less, and is BSD licensed, that's the only reason I have behind the choice, so no biggie.
Now ruby on the other hand, has little room for compromise. I have discovered a guy who builds ruby off the svn nightly, and installs his gems via rubygems, so I now know it can be done. I'm going to try and figure some things out.
As far as your three options are concerned, I've been seriously considering option 3. i've been following some of the BSD ruby developers lists online, and in the next month or so I plan on flipping through the developers and porters handbooks.
Right after I get FreeBSD 8.1 working on a machine here!
Post a Comment