A shotgunning look into my random thought patterns, turning up surprisingly non-random, non-trivial connects on several hoopy wavelength. Your Mileage May Vary.
Thursday, December 9, 2010
RSpec Book is Out!
I bought this book like forever ago, and it's finally in print!
I want to say that so far I like the paper version as much as the electronic, and now that I basically only have one computer it makes following the examples in the book so much easier.
If you are looking to learn behaviour driven development, and the tools behind it, pick it up!
enjoy!
ok,
I'll go back in my hole...
Thursday, October 28, 2010
Using Ruby for Something Not Rails.
So, I fell in love with ruby before I knew what ruby on rails was about. I started using ruby because I remembered the thrill of using my computer to actually write the software I needed to get a particular job done. I especially was excited because with ruby, I could run something across many platforms with little modification, in theory. In the old school world of line numbered BASIC, one had to tailor tune the BASIC to his or her platform. I used the Commodore 64, perhaps the creme de la creme, but still, different than AT&T, Tandy, or IBM. Often, the differences were subtle, and I hated going to school, and using the TRS-80's or Apple IIe's because I felt they changed the BASIC only because they wanted me use their software. Incidentally, this became the seeds to my use of Open Software, before I knew about Richard Stallman.
Back to the Ruby.
Chris Pine is my hero. If you've never read Learning to Program you should, even if you are the most amazing 1337 h4xx0r there is. I discovered it while trying to find a language I could love as deeply as I loved my Commodore. Ruby is it.
I worked my way through the book, and began using ruby for various things in my computer, the most coolest of which is updating itself.
That's right, I use ruby to update itself.
Every whenever I want to, I build ruby from source using a little script I hacked together on a whim. In the process of writing it, I learned how ruby does things like change directory in a linux environment, and how adding a puts in there can make things more verbose.
Here's the gist of it: upruby I know it's not much, but it's powerful, and can be improved, and I am interested in hearing how you would improve it. I've been thinking of parameterizing certain elements, and having the file run off of a configuration file. I keep everything invisible to non admin users for obvious reasons, so I don't have to worry about maliciously destroying my /dev/sda. I've also thought about making it a general script to update a lot of different things, and making it so it will run as a cron job, or perhaps only run when I am expressly logged in as the root user, and not merely sudo runnable, just because I don't want to have an issue with something taking a while (like updating all the gems) and have to enter my sudo password multiple times.
I am interested in hearing about how you would handle this situation. How would you adapt this script to run your updates?
That is all!
Next post is going to be all about amateur radio! I hope you are as excited as I am about that!
l8rz,
gb hoyt
Thursday, October 14, 2010
New Ubuntu, or My Meerkat be Maverick!
Let me say this,
I am getting tired of installing a new OS every Six months, lol.
That being said, Maverick Meerkat is pretty slick. I did a fresh install, completely wiping out my old system, although I did do quite a bit of copying my files from a backup once the installation was complete. Everything seems to run a little better now, I am using the "Proprietary" video driver, I haven't installed apache or Drupal. The machine is running smoothly, and cooler. The fans definately are not working as hard. Maybe they finally got flash right! I have installed ruby, from source, following the instructions I previously gave for Ubuntu 10.04. I didn't doubt they would still be valid, having done this long enough to understand when I stand a chance of changing something that will break everything else. Everything is in a different font than before. I don't understand how that makes things better, but I think it does. Somehow, I have convinced myself that the rounder looking font has made the electrons move faster, and therefore, boosted computer performance.
In a nutshell, I like it, but I'm tired of liking something every six months.
l8rz.
Saturday, October 2, 2010
Live From The Heart of Possum Hollow: Life in the fast lane means you have to duck the pigs in flight.
Friday, October 1, 2010
FLPR vs LAMP
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.
Tuesday, September 28, 2010
Source Installation of Ruby in Ubuntu
First things first:
1. You will have to uninstall your current ruby. All gems, all ruby libraries. Everything. When you build something in Ubuntu, the resulting binaries are kept in a different place than if you install from a package. Installed packages go to /usr/bin/ and home rolled binaries go to /usr/local/bin/. The difference is huge. Packages installed in /usr/bin/ are maintained by the package manager. If you delete a package there, your package manager (synaptic) won't like it. Packages installed in /usr/local/bin are your responsibility. You will have to keep the binaries installed there up to date. No big deal, I'll share a little script I wrote (in ruby) to do just that after I am done explaining how to get to that point.
2. Go ahead and download the source code. Normally, I would tell you to grab dependencies, but I want you to get the source code now for a reason. Read this page, http://www.ruby-lang.org/en/news/2010/08/18/ruby-1-9-2-is-released/ and then download the source that ends in .tar.gz
3. Open a command terminal (Applications > Accessories > Terminal Its Icon is a black box with ">_" inside of it.
issue the command "tar -xzvf /path/to/tar.gz" if you download things to the Downloads folder it will be
tar -xzvf ./Downloads/ruby-1.9.2-p0.tar.gz
notice the little dot in front of the first /? that means "start looking in this directory."
You can use the tab button to complete the command, for instance I would type tar -xzvf ./Down
4. after the tar command works its beautiful magic, type
cd ./ruby
that will put you in the ruby source code directory for ruby extension libraries. now type
ls
to list out all the files and directories in this folder.
What I am having you do is look at the various pieces of ruby that may or may not install when it's installation time. It will help you install dependencies.
5. Time to hunt for dependencies! Open synaptic and start searching. Use the real search tool, not the quick search. The packages you need to install end in "-dev". These packages are actually C header files the make tool will use to build your ruby!
6. You still have your terminal open right? Most of the entries you see are directories that contain the source code for building different parts of the ruby library. Ruby doesn't *technically* need these these parts to be ruby, but they do make ruby useful. The bad news is that you have to have the dependencies installed in order to compile the source contained in these directories.
7. Back to Synaptic! Before you build ruby, you need to install some packages that will let you build anything. First search for something called "build essential" The first package that results will let you build source code, click it, and get it ready to install, you are not done yet. Second, search for "autoconf". You will need it to preconfigure the building of ruby. Next search for a package called "bison" You will need to check that one to install as well. The final tool you will need is "subversion", which is how ruby keeps track of itself once you are ready to download the absolute freshest source code. Now let's find some libraries that ruby depends upon. First, search for "readline dev" This one is tricky because you will find the package you want listed as "libreadline5-dev" there are a lot of choices, because there is much variety in the readline library. I compile my ruby with readline 5. Now search for "openssl" This one is really tricky, because the library you actually want to install is called "libssl-dev" There is wisdom to be gained by looking around at the results of your search, namely that there are libraries that have the name 'ruby' in them! Do not install them! You are on a different path. Their path is the one you are leaving. One benefit of installing the openssl development library is that it also depends upon the zlib library, which ruby also needs! Two dependencies for the price of one!
8. Install the packages. It may take a while.
9. Now that those packages are installed, you are ready to go back to the terminal and begin building ruby. Go to your terminal and type "cd .." That means, "change directory, to the one immediately below this one." That should be the root directory of your ruby source code. The magic begins now.
10. First, type "ls", and look at what is there. A lot of files end in ".c" : That's your source code! In a minute it will become your ruby mine. Next, you need to type "sudo autoconf" at the command prompt. That will generate a "configure" script that you use to configure your source code to your environment.
11. next you will need to type "./configure --enable-shared" notice the . and the / in front of configure. they mean 'use the configure command located in this directory, furthermore, use the flag that will configure the source to generate shared objects library.' The shared objects library is important if you want to use shoes, or rails.
12. Time to make! Type "sudo make" and watch the code work. It should take a few minutes, but at the end, you will see success.
13. Test the code! Type "sudo make test" to test the code. If it passes, you will be ready to install.
14. Install the built code! Type "sudo make install". This will install the code you will be running.
15. Now you need to clean up your mess. You want to leave your source clean, so you type "sudo make clean" to clean it up.
16. You have the ruby! Yippee, but you are not done. First visit the Ruby Core Page and look at how to install the source code.
Mull it over!
Are you really bold?
http://pastie.org/1187982 for my script on updating my ruby.
Tuesday, May 11, 2010
New Jorb!
I have a new one. Effective May 22nd (first day of work is technically the 24th), I am transferred to the Manufacturing Systems department as an intern! Yays! I get to be the do-boy again! Apparently I'll be doing interesting things with databases and VB for Access. Yes, I said Access, as in that Microsoft product that costs beaucoup de l'argent! Biggest change for me is that this is a day job. For the last 4.5 years I've worked the night shift doing something I am not even remotely interested in doing for another day in my life.
The company I work for is a good company to work for, but many times you have to take some 'less than desirable' (technical term used is 'crappy') job to get your foot in the door. When I first took this particular job is was something to do in the mean time while I continued raising support for the homeless ministry I started in Orlando. Economy and my own fund raising inexperience meant that things kind of floundered around until I had to give it up. It's always been a dream of mine to help churches understand that God doesn't take the 'special' and make them do great things, He starts with the willing. Watching my dream die a slow death was hard. Not to say it's dead, volunteers in Orlando continue the work to this day, but my dream of doing it full time is not working out. Plan B became a career in field of problem solving known as programming. Publix (my current employer) has many positions in the IT field, and I began pursuing a job in that department about two years ago. Seeing as my degree was in an 'unrelated' field, I began taking classes to complete a degree in computer sciences, and that is going ok, Sometimes better, sometimes worse. At my current rate, I'm about five years from a degree, haha!
that stinks.
So I'm taking a chance here, breaking out of a place where I don't like working, but that has some level of comfortability. It's a long row to hoe I'm on, but the work is steady, and I'm moving to a more rewarding job now intellectually. I also will be looking for full time work at the same time. Who knows, a year from now I could be slingin' C at production line controllers, or introducing the web development team to pair programming. Mostly, I'm grateful for the chance to meet new people, and be home at night. I think it will help my girls if I'm home at night, with mommy.
l8rz!
GB HOYT
Friday, March 26, 2010
Totally Random
Love and Grace are hard.
that is all.
Saturday, February 20, 2010
The... "Recipe"...
The point of this post is to provide my AMAZING recipe for red beans and rice.
However, I am hoping to kickstart some discussion about programming processes. For me this is an intersection of things, we are at a nexus so to speak, between how my brainz applies thing I learn to reality. Welcome to my worldview. First things first, here's the recipe:
Red Beans and Rice
--GB Hoyt style--
(feeds 8, maybe more)
ingredients:
- 2lbs red beans, dried
- 1 cup all purpose flour
- 1 cup olive oil
- 2 32oz boxes of chicken broth
- 1 head of celery
- 1 green bell pepper
- 1 red onion
- 1 bunch green onions.
- 2 tsp rubbed sage
- 2 tsp white pepper
- 2 tsp black pepper
- 4 cloves of garlic
- 3-6 bay leaves
- garlic salt (to taste)
- Tiger Sauce brand hot sauce
- Sausage, something with flavor, traditionally, andouille
NOTE:
To make really good red beans and rice, that will feed about eight adults all the beans they want, you need a two pound bag of dried beans. That is important. Early iterations containing canned beans were judged to be definitely inferior to later iterations containing more labor intensive dried beans.
30 hours prior to serving time: in a large bowl, start soaking the beans, cover them with about 2 inches of water.
Right before bedtime: Drain and refill bean water.
Right after waking up: Drain and refill bean water.
The previous steps will help eliminate the 'aftereffects' of eating beans, but it's not fool proof, I understand the Amish let their legumes sprout for the same reason before cooking, I haven't tried that yet.
About five hours prior to serving time:
Make a roux:
in a black skillet, or pot you will cook beans in, heat the olive oil to about the temperature you would cook hotcakes at.
combine flour with black pepper, white pepper, and sage. Slowly add the flour mix to the hot oil, stirring often, try to evenly add it across the bottom of the pan. There should be enough flour to make the mixture thick, but not gloppy. It's an art, making roux. Let the flour darken until it's a dark brick color. you don't want to scorch the roux, so cook it slow, only turning the heat up if you have to.
If your Red beans are to be cooked in a different pot, you can go ahead and start warming up the chicken broth, adding the bay leaves, garlic, and a little more sage. When the roux is brown enough, add it to the broth, stir well, turn the heat up and bring to a rolling boil. If you are cooking the beans in the same pot as you make the roux (this is ideal, dutch oven to be 'authentic'), add your broth and spices to the roux. When the broth/roux mix starts to boil, drainthe beans and add them to the pot. boil on high for about 15 minutes, then turn heat down to a low boil. It should be about 4-5 hours till serving time. Two hours before serving time, dice the onion and bell pepper, and slice the celery to the mix, stirring each into the mix. then slice and add your sausage, let cook for about two hours. If you add the celery, bell pepper, onion, and sausage too soon, it will break down into flavourless goo, too early, and it won't marry. I find that dicing the onion and bell pepper, and leaving the celery in bigger chunks marries all three flavors, and adds great texture. Cook 4 cups of dry rice about half an hour before serving time. I also make cornbread to go with this meal. Shortly before serving, chop the green onion, and let each person add to taste to their dish. This is a functional garnish. Not only does the onion look pretty on top of the dish, but it is what really sets the flavor off.
enjoy!
Now, what does this have to do with agile development? Namely, this recipe was developed using Behavior Driven Development (BDD)
It contained "Domain Driven Design" where the domain is the collection of people eating at my house on Friday nites that I am off.
It contains "Acceptance test driven planning" because if the Domain disapproves of the flavor, it must be modified!
It also contains "Test driven development" because certain assumptions were made like "The red beans and rice should be slightly pasty when served", early iterations were too watery, then too gooey, finally, the magic ingredient (the roux) emerged when an older recipe was perused. I know you don't see but what one recipe here, so this is where I pose a question to the group, What's the next test? Where goes the next iteration? Should I codify the sausage, and say "always use this sausage", should I detail out the roux? The right roux has definitely played the biggest part of making this dish right. That, and waiting till the end to add the green onion.
l8rz!
Friday, February 19, 2010
Yes, It's True.
It's red beans and rice day, officially, and it always is that I work really hard at delivering this meal on friday nite. going to try some new sausage in the recipe, maybe some kielbasa, nothing too spicy, although if I think I can get away with it, I would like to try a little andouille, or something equally "Louisiana" flav0red.
I tried to listen to a conference yesterday, and that was full of FAIL.
ok, so I have an idea, and as far as I can tell, no one is doing it yet, so I am now left with that dangerous conundrum, to collaborate, or to not collaborate? Basically, I am not looking to do anything new just yet, just trying to do something in a new way, synthesizing some goodness into an otherwise dreary outlook, and having some fun learning about Eclipse. Such as that is, I am trying to put a little jruby on machine(s), maven, some Android dev stuff, all in an attempt to tidy up my brainz and get to hacking my way around a Motorola fone, like say a Droid (snicker snicker), maybe I will own one by the summer. My Bro-in-law has a droid now, and I am trying to think of a good app to write for him, he's in the landscaping industry, so I've gots a few ideas. right now, I have a couple of ham radio ideas also floating around my noggin, but in order to really work them all out, I must first attain some knowledge of how exactly everything fits together.
I ain't gonna lie, Eclipse got a learnin' curve, I mean, POM, Java, all this java junk is weird to me right now, I admit, it scares me, but I see in it all a potential to take me to the next level. I have got to do it! Been a while since I've had a case of the "got to"'s like this.
So,
I have goals.
Goal 1. Learn some Java.
Goal 2. Learn some Eclipse.
Goal 3. Develop useful app for Android using BDD.
n'om sayin?
Thursday, February 11, 2010
lots of random things...
I like me for me!
GB Hoyt