Assuming that you have a basic Heroku environment all ready to go and possibly even pushed to the Heroku servers, the main thing you’ll want to do is install Postgres. The current version of Postgres on Heroku looks to be 9.3.5 according to the command:

heroku pg:info

So you probably should try to stick to that version or lower even. I ended up going down to 9.0 just because of various issues I had along the way. One thing that you should do is get the x86 version and NOT THE 64-bit version. The pg driver for rails is not compatible on Windows for whatever reason and you’ll repeatedly hit errors of not being able to find the correct libpq libraries.

Once you get your packages and have a Postgres installed on your system, you’ll want to edit your system level variables so that your path includes your installation to the bin directory. To do this just go:

• Open Windows Explorer
• Right click on Computer
• Click on “Advanced system settings” on the left pane
• Click on the “Environment Variables” under the “Advanced” tab for System Properties
• Then edit the PATH variable under “System variables”. Add the path to your local Postgres installation (e.g. “c:\Program Files (x86)\PostgreSQL\9.0\bin”)
• Click Ok

If you’re already in a command prompt, you’ll probably want to restart it in Admin mode so that you can see the updated System variables.

Now, in your rails installation, you will want to run the commands:

gem install pg --pre
bundle install

The issue here is that there seems to be some compatibility issues with the current 0.18 driver. Using the pre-release version seems to solve it. One way to test whether things are busted if just trying to turn your server on by issuing out a command like:

rails s

If things work out, you shouldn’t get any issues (Cannot find/load pg_ext is the common error here). You can even try running a migration to make sure you can connect to your database from rails.

Unfortunately, for myself, I ended up spending almost half my day trying to get this setup correct. I did things like downgrading from 9.4 to 9.3, moving directories around, experimenting with the pg driver in rails, spending time trying to figure out how to run the command prompt as Admin for a specific directory that had no content if the prompt was run elsewhere, etc. It was a real pain overall with no unified documentation to walk you through. Also, I’m a bit sad about not being able to take advantage of the current Postgres version just because I just want to make sure everything works with my current setup. Of course, I can upgrade it in the future but having an older version is a safety net in terms of proven support.

At any rate, despite how simple the end solutions are, much of what happened for me was just running through hundreds of useless questions and older articles that did not seem relevant anymore. So hopefully, by posting my experience in this situation, people can avoid this problem for themselves in the future.

Of course, the other issue you might ask is, “Why the hell are you developing on Windows in the first place?” Unfortunately, my Windows machine is my most powerful box for development and my Macbook simply lacks power to handle a lot of what I need to get done at this point. Hopefully, if I can get some money, I’ll be able to get a more powerful Macbook and avoid this unnecessary suffering. But in the meantime I have to make due.

The post Postgresql on Windows 7 and Rails Installation Nightmares appeared first on Kontroversial Keith.

Already, I’ve found that Rails by itself has a fairly large learning curve. Most examples can you up and running quickly. However, anything beyond your typical CRUD “Hello World” application is going to require a lot of trial and error. Triple all the difficulties if you never have or barely touched Ruby, which in itself has its own problems as well as adapting to CoffeeScript and SASS for CSS.

One of the more interesting features that has been causing me both frustration and delight simultaneously is the scaffolding feature. Scaffolding essentially creates a lot of basic CRUD boilerplate type of code. This is a neat feature…if you have a pretty good idea of what you want to build ahead of time. However, this can get sticky quickly once you start customizing the boilerplate code and expanding out your models. There are ways to handle this scenario such as destroying the scaffold and/or using migrations. Unfortunately, I think by destroying the scaffold, you’ll lose your customized code in the process.

So what I think ends up happening (at least from a n00bz point of view) is that most people end up using migrations. Migrations, just like scaffolds, are both a blessing and a major pain in the ass. The concept of a migration is that you allow the framework for the most part to manage your database. This is a GREAT THING. I really love this aspect because it pretty much standardizes the implementation for dealing with your database. All too often I’ve encountered sloppily implemented homebrewed schemes for handling database changes. In turn, there’s no standard practice that people can easily turn to outside of the owner for these changes (and/or the DBA). With Rails’ method of migrations, you have a methodology for handling all changes and you get the community, documentation and support all rolled into one framework.

That said, the migrations methodology that Rails provides can be annoying. Now, I haven’t gone that far into migrations, but my experience so far has demonstrated to me that Rails can get sloppy quite quickly. For one, there’s a directory that contains all the migrations. I can easily fathom hundreds of migrations for complex applications in that directory. Also, there’s the naming of migrations. Part of the naming convention makes sense and actually can be helpful since the naming convention is somewhat descriptive. However, something I’m wondering is how one ends up dealing with constant change to a model/table over time. It feels as though you could potentially end up with a ton of redundant and/or misleading names.

Lastly, the migrations themselves are all timestamped. While the intent is nice, what really Rails needs to implement is a local version control system for migrations. It feels as though working off a single model and evolving it constantly would be better handled through version control as opposed to the timestamp system. I heavily dislike the idea of constantly writing and naming new migrations for any additional changes I need to make to my schema. By doing this along with having the version control system, perhaps Rails could intelligently work with your models and views to update the necessary attributes rather than you having to manually go through and editing them after you generate your scaffolds. In addition, you could have cleaner versions of these changes being propagated to the real central version control system.

Moving along, the next part I had a bit of stumbling on is the notion of attr_accessor vs attr_accessible. I wanted to create an attribute on one of my models that was not linked to the database. In addition, I wanted this particular attribute to have its own default values (gee a model that isn’t just a fucking clone of a row from a database? Who would’ve thunk?) Believe it or not, this situation isn’t as easy as it sounds, at least from finding reasonable documentation on the subject.

So part of the problem is differentiating between attr_accessor vs attr_accessible. attr_accessor essentially creates your getter/setter methods for an attribute in your model. on the other hand, attr_accessible imposes some security on what can be sent to the constructor when creating a new instance. The example given that I found was something like a password or social security number where you might not want to just send blind data in. But that’s where my confusion comes in because apparently you can still access your attributes normally when you use the attr_accessible method. So I’m still trying to figure out the point of this. The only logical thing that came to mind was that you could create non-column based attributes by utilizing the attr_accessor method. An example is a password confirmation field. There, you do not need to persist the confirmation but you still need to validate that it exist and matches the password from a form.

Well, great. So why did I need something like this in the first place? In my application I have a large number of attributes that are pretty much clones of each other. The display logic pretty much is repetitive so I had a choice of either hard/hand coding each attribute or attempt to automate the generation of these attributes in my form. I wanted the model to have the knowledge of which attributes would be required here just in case I needed to use this logic elsewhere in the future. In turn, I would define these attributes in an array attribute that I could iterate over in my form. Sounds easy? Not exactly with Rails.

First problem: where do you initialize this information? After doing numerous google searches, the common denominator ended up being in the after_initialize method. I tried using this methodology where I would do something like:

def after_initialize
    self.default_stats = ['age', 'strength', 'intelligence', 'wisdom', 'willpower', 'dexterity', 'personality', 'reaction', 'constitution', 'comeliness', 'leadership', 'perception']
end

However, when I attempted to access my default_stats attribute in my view, I kept getting a “Method Not Found” error. This occurred during an edit action where my controller would instantiate the related object and pass it back to the view. I have no idea why my array wasn’t properly getting initialized. So for now, I ended up cheesing this a bit by changing that function into something called “stats”, calling it in the view and assigning it to a variable to iterate over like this:

  <% stats = @race.stats%>
  <% stats.each do |stat| %>
  <div>
      <%= f.label :name, stat%>
      <%= f.text_field stat, :size => 2, :maxlength => 2%>
  </div>      
  <% end%>

This code would almost work except for one issue: stat. Here “stat” ends up throwing a “method not found” error in the f.text_field statement. Actually, what goes on is that the stat variable ends up becoming interpolated into something like “age” or “intelligence” and those in turn end up receiving the “method not found” error. Why is that?

It’s because our friend attr_accessor requires these attributes as well. Wait what? The fields from my default_stats attribute are actual column names that I’ve already defined in the attr_accessible method for that particular class. I think because I added them late and that they did not have any value, they ended up just disappearing off the face of this map and can’t be loaded for whatever reason. So to compensate, I ended up just adding them to the attr_accessor method and the view ended up working.

I’m probably bungling a lot of ideas up but certain aspects of Rails just haven’t clicked for me yet. I suppose I could’ve just put them into a local array in the view instead. But it just felt wrong. I want my views to be dumb about certain aspects that only my models should know about. I’ll probably re-use this mechanism in a different area. I shouldn’t have to search through my views to pull out logic that really belongs in the model.

Yet this example illustrates a few frustrations some simple, possibly common things you would find in many frameworks that are not adequately explained upfront. Again, it feels like my inexperience with Rails might be de-railing me (nyuk nyuk) but I wish things like this were more apparent. Wouldn’t it just be easier to have all your attributes lined up with the ability to define them in a single shot without going through all these other odd mechanisms? I do feel as though I’m jumping through a few unnecessary hoops to accomplish something most OOP structures have as a default.

Lastly, I dabbled a bit with the unit testing aspect. This was one piece that sold me on wanting to really learn Rails. I noticed that Rails has several different levels with testing, including both unit and integration testing. Also, just in browsing through the directories, I can see performance testing as something I can eventually delve into. Setting up the tests with Rails is fairly easy as Rails pretty much generates all the necessary files in the right places to get you started. But you’re pretty much on your own from that point on. As of now, I’ve only just tested a simple model by writing test around the validation aspect. When I ran the test, a plethora of output poured out and I had to scroll around to find out exactly what went wrong. The issue wasn’t very descriptive and I’m certain I’ll need to figure out how to improve upon making the messaging far more meaningful.

I felt slightly disappointed thus far with this. I know there’s various books/sites dedicated to test driven development using Rails as well as integrating them with Agile methodologies. While the resources are available, I kinda was hoping that the framework would force me by default to get into the habit of writing unit tests. Instead, once again I see the unit test aspect psychologically as just necessary busy work that can be indefinitely delayed.

Sure, enforcing unit testing on day 1 might be overwhelming for people who want to adapt Rails. The idea reminds me of how my old programming professor from UCI once told us how Java was a terrible teaching language because of all the various concepts you’re forced to teach on day 1. But I think that getting into good habits early is better than forcing yourself to change later on. In short, it feels like a missed opportunity for the framework.

That said, I haven’t gone very far yet with Rails. I created a pretty decent project for myself just to ram my head against the various cases of developing a more complex application. I’m hoping that over time as I improve these issues slowly minimize and that my application can be built faster. Also, I would love to deal with more esoteric aspects of the framework so that I can really learn the boundaries of what’s possible.

With all that in mind, one thing that I think about is how one could possibly utilize these concepts with other frameworks. For instance, there’s Zend for PHP. Zend is quite good in that it’s mature. But it’s really piecemeal when it comes to the design since it obeys the “loosely coupled” notion of OOP. I think that things like Migrations would be an interesting piece in the Zend puzzle. I’ve seen some systems like Magento employ a migration-like mechanism. But I feel that there should be a better plugin for Zend that does some of what I mentioned (like the version control aspects)

Despite my complaints, I’m still excited to learn more about Rails. I’m trying to keep an open mind when it comes to learning the in’s and out’s of the framework. I love the fact that it’s one of the more mature frameworks around and has a great deal of support. There’s a lot of really cool technology associated with Rails and I hope that with some dedication and this project, I can learn enough to become a reasonable developer with it.

The post The Learning Curve of Ruby on Rails appeared first on Kontroversial Keith.

Right now, as I’m learning Ruby on Rails, the thing that strikes me is the notion of how the database ends up becoming a stupid data store. It’s really just an artifact of infrastructure as opposed to the driving force behind a company. In all honesty, I started to become suspicious of relational databases back when I worked for Demand Media and spent time on Livestrong. A lot of problems occurred due to how our Mysql Database would occasionally have issues scaling. My team lead and I started to become extremely frustrated by being tied down through the database layer.

In order to avoid the scaling problem, you end up turning to non-relational methods to handle your problems. For instance, one of our tables at the time was at the half billion row mark. Because of how it was primarily a constant write table, we needed a solution to evolve it. At the time, the solution we ended up going for was archiving most of the data and truncating it. Then when a user wanted to access older parts of their history, we would unarchive it upon request.

But note the language I’m using here. I’m trying to avoid using database specific terminology to describe a problem and create an answer. But that’s where you need to think more on an abstract level rather than a fine grained level such as a database row/table/column at times. And that’s where you need to move from the data layer to a business requirements mind set.

Now, I’m certain that most people in tech will all agree that solutions must be centered around business requirements. Although that’s certainly a common bond, everything ends there since people end up doing work arounds. Quite often, these work arounds exist as a result of the inflexible structure and/or nature of the database. Of course, applications also have their limitations but databases tend to be more rigid because of data.

That’s where I like how systems such as Rails have certain control over more static data elements of data through notions of migrations. Also, things like Rails seem more fluid in design because you’re attempting to do more abstractions. For instance, I encountered the :references value which allows one table to hold a relationship (one-to-many) to another. Rather than bothering with all the details of the database such as foreign keys, indexes, constraints, etc., you allow the application layer to manage that.

Part of the reason why I like this is that the technical details for an application can take away from significant development time. Having the application manage those aspects alleviates developers from useless duties and allows them to focus more on business logic. Anything that saves on time is a good thing for me.

One thing that I have noticed as the industry continues to grow is that the role of the DBA is slowly diminishing. I feel that DBA came about as a result of Oracle being so dominant early on and existing solutions not having an open source, well documented alternative. In turn, DBAs ended up becoming extremely powerful, commanding high salaries and often times enacted fairly draconian policies with regards to data. More than that, they would attempt to control the business layer by forcing developers to house all their business logic within the database. In turn, that forced applications to utilize incompatible SQL and stored procedures and providing little flexibility as new cheaper and potentially faster/better solutions appeared on the market.

Unfortunately, you had varying qualities of DBAs. Some were actual computer science students who knew about application development. However, others seemed more like people who just had fancy certifications but knew and potentially cared little for application development. Instead, some of those more poisonous individuals would utilize their power as DBAs to have all decision making processes filter through them. If they lacked the passion and/or knowledge of application development and also were difficult people (and quite a few that I’ve encountered were), the application development process would end up becoming a huge, unnecessarily bureaucratic nightmare.

The thing is that as a developer I want to build things without the issues of unnecessary forms, reviews, etc. to get to an end solution. As an architect, I want to develop solutions without thinking about artifacts upfront. I want to focus on the problems then break down the problems rather than starting with say a table and defining all the columns. Once you go down the latter path, it becomes a slippery slope because you end up working around the table as opposed to the problem and making that solution more scalable.

That isn’t to say that data isn’t important. Of course, these days it becomes a huge part of the genetics that compose an organization. But in the application development process, I really do not like it being the center of attention. Similarly, I think picking a technology in advance and trying to fit it with a business problem is equally wrong. Focus on the problem first.

Lastly, I talk a lot about Ruby on Rails. Although I decided to pick Rails for my next project, it’s mostly because I want to learn about it and how to really utilize it. That is somewhat different than say arbitrarily choosing Nosql as my data store because it’s the latest and greatest. If it’s a learning situation, then choosing the technology in advance is fine. But don’t play with others’ money if you have the chance.

The post Data Driven Development: The Mistake I Made By Moving Towards This appeared first on Kontroversial Keith.

Usually, while my mom undergoes therapy, I’m at a local coffee shop working on things like writing or coding. Yes, I’m trying to get back into coding. Once in a while I get a serious call from a recruiter. I keep my price high to see if they can get me a serious offer. But at the same time I’m slowly testing the waters in preparing to re-enter the workforce. Still, I want to keep my hunger strong for technology and am starting to look into adding a few pieces of technology into my belt.

The primary two I’ve been going back and forth on are Ruby and Python. I feel that PHP is slowly running its course with me and that I no longer want to use it as a crutch, much like how I felt Perl was a crutch for the longest time. While there are still plenty of jobs for Perl and PHP, it’s always good to increase the variety of what you know. Right now, we’re seeing Ruby and Python make pretty big strides into the industry.

Python is something that I dabble in on occasion. The big thing about Python is that many universities are now using Python as a teaching tool. The readability and “one way to do things” methodology make Python an appealing language to teach students. However, the real impact of Python in the technology industry, for me at least, is seeing the number of jobs out there.

Recently, I did a quick job search comparing PHP, Perl, Ruby, Python, Ruby on Rails and Django using Dice.com to see the numbers. The big surprise for me is that Python, at least according to my search, resulted in a greater number of total opportunities compared to PHP. Perl still dominates in the language area, but this move to Python may be because of its connection to universities. However, Rails still exceeds Django when it comes to the framework side of things.

For myself, I felt myself at a crossroads. I want to learn Python because of the mass appeal and longer term potential. However, Rails does have a significant number of pluses beyond job opportunities. A few that I perceived are the community backing rails, the number of solutions and the wide support. Also, when I hit the bookstore, I only could find a single Rails book so it pretty much cemented my decision. Oh and the “cool” factor that seems to encompass the brogramming groups.

That isn’t to say that I’m unwilling to learn Python nor scorn Django. In truth, I did pick up Django a while back. I really like how Django nicely can integrate with Google Apps Engine. From what I’ve seen Django has some nice features like the admin tool, which is similar to a kind of scaffolding for your models. But my gut instinct tells me that just the number of job opportunities and the community support and possible solutions make Rails a better short term solution just to give myself something to chew on. I might, from time to time, return to Python but I would like to master the Rails framework first.

I ended up picking up the Learning Rails 3 book from O’Reilly. There were some elements that really appealed to me like migrations and unit testing. Also, I read about other integrations such as coffeescript, another thing I very much am looking to learn. So right now, I’m trying to set myself up with Rails and am doing some basic tutorials.

One thing I have noticed about Rails, at least on my Macbook Pro with OS 10.6 Snow Leopard, is that despite being installed, Rails did present some problems. The main issue seemed to be that Rails was not properly upgraded. So I spent most of the day trying to upgrade Rails and Gems to get it to work. Using a few online tutorials/guides, the Gems/Rails upgrades were not that easy and I often found a large number of dependency issues that required me to do repetitive upgrades. I’m not sure if I’m just a noob at all this but that didn’t impress me.

But once I got the basics installed, setting up a simple CRUD application with scaffolding and model validation was a breeze. I have a few ideas for some projects for Rails that I think will make great learning projects. So I’m really pumped to dig my teeth into more of the advanced topics down the line.

Once I feel more adept with Rails, I will be looking into picking up an IDE. I was recommended RubyMine. However, the cost is a bit high right now so I might wait as a friend mentioned it goes on discount once in a while. If not that, then I might try Aptena as I believe they have a pretty good Ruby/Rails integrated environment.

Also, I mentioned that I ended up giving PyDev a try. Since the recommended IDE of PyCharm also is a bit on the pricey side for me at the moment, I decided to give Eclipse the go motion again. Adding PyDev into Eclipse was a breeze and after seamlessly detecting my Python environment, I was able to get a few simple scripts going. I feel that Python might be one of those things where I’ll have to learn something like a Django to use. The problem is that most of my style of coding revolves around the web. So without a base framework to do all the dirty work, it becomes difficult finding the motivation to learn every little detail about a language. Compare that with Rails at the moment, where I can easily think of a few cool projects to whet my appetite in progressing with Ruby.

Beyond programming, I’m trying to keep my artsy side going by getting back into literature. Along with the Rails book, I picked up Pynchon and Murakami. But before I can delve into those guys, I need to finish up Gibson’s Zero History. I bought Zero History a few years ago but barely made it through 30 pages before recently picking it back up. Most of my motivation for delving back into reading is that I want to do more fantasy writing (in which I’ll talk about in a minute). It might seem strange to read someone like a Gibson for getting inspired for the fantasy genre. However, I’m still waiting for the new Stephen R Donaldson book that concludes the last leg of the Thomas Covenant chronicles and that’s not due until the end of the year (supposedly).

That said, probably some of the best advice I’ve ever received when it comes to writing is that you should always be reading as you write. I can see how this is valid. After putting down World of Warcraft, I honestly lacked inspiration for anything. My mind felt blank and I struggled with writers block for a few days. Although I still have issues coming up with new material, those first few days really were awful for me as I lacked anything satisfying to say. Hence, picking up someone like a Gibson just to get some ideas flowing.

Gibson though is great because he’s very detail oriented and has his own style that compels me to read him. His characters and story plot lack in favor of all those details. But I need the vocabulary, the prose, the sentence structure and rhythm to help resuscitate those dying nerve endings in my cranium.

I won’t do a review just yet of Zero History as I want to finish it up. Right now, I don’t have a solid opinion and am letting him guide me through the story. Most of what I’m getting out of Zero History are the details of how he’s using a contemporary setting to embellish the world. The whole series has been great in that you can see how he’s taking what’s existing and pulling it all together as opposed to guestimating what the future looks like. I still think Gibson struggles because he might sometimes not be able to keep up as fluidly as someone like myself who directly works with technology. However, I think he does introduce a very fresh point of view (like employing Twitter for creating espionage related accounts).

So again this all leads to my fantasy writing. Oh what a struggle that is. I’m never quite satisfied and it’s a real pain to come up with things that might feel fresh for readers. I think part of the problem is that I’m not able to fully immerse myself in the fantasy environment that I want. Possibly, that’s due to not fully comprehending what I want. I always felt that fantasy writing is about being in a place you’d rather be. While the premise is ideal, in practice trying to arrive in that environment is much more difficult than it seems. For me, I want to detail everything, create histories and links to everything. It becomes quite overwhelming after a period because you can go in so many different directions. Some might prove fruitful others are a complete waste of time. And then there are details that are so critical to readers that you take for granted and end up mistakenly leaving out.

At any rate, I decided to kind of skip ahead today because the sections leading up to this point are things in which I’m struggling far too much with. I can’t reveal in depth what I want to write about but I have to say I can completely understand when writers pull elements back into the present. It’s just so much easier to relate to things around you.

I’m going to continue doing this “cool things” aspect of my blog. It might be boring for the more outdoorsy type of reader, but I wanted to share more of the interesting hobbies I’m doing as I try to help my mom recover.

The post Cool Stuff: Ruby on Rails, PyDev, William Gibson, Fantasy Writing and More appeared first on Kontroversial Keith.