Week 4: Databases and Servers
This week we moved on from databases to servers. Some people in the class thought it was harder, LOVED doing database stuff, and wished we could stay in it longer. Those people are not me. I am happy to move back into ruby land where I can make whatever objects or functions do whatever it needs to get done. All that matters is that I parse the incoming data correctly, and spit out the right data in the right format. I love figuring out how best to do the in between part. It’s the best.
Working with servers and active record, there is some rigidity, mostly built-in stuff so I don’t have to build the whole interface between both the server and the database. I have to remind myself it really is helpful, and not just there to cramp my style. I don’t mind it for the most part. The problem comes when I want to do something fairly simple, like call or access something I KNOW exists somewhere inside what I’m using, but I can’t get to it.
For example, working with Sinatra, I wanted to take a get-do and within that, if some conditional failed, call the default Sinatra 404 page. I’m sure there is a fairly simple way to do it, but I spent an annoyingly large amount of time trying to do just that (and failing every time). I ended up just writing my own.
It will be good to get familiar with the intricacies of how these interface layers work. Unfortunately, I think being in an intensive coding bootcamp means we don’t have time to slow down and dig into understanding *everything* happening under the hood. I mean, that layer of abstraction IS there to make it easier to use.
With a bit of time, I think I’ll just get more comfortable with what I can do and how to do it — as well as when I need to google how to twist it to my will.
Either that or I’ll just have to accept it.
On Friday, we visited High Alpha. They gave us a tour and had a panel to answer questions. It was great to hear some of the in’s and outs of some different High Alpha companies, and learn how they work and what it is like to work there. It was also great to see an example of a “real world” environment, a real place that does development work, and that often does hire Iron Yard grads.
That seems a bit obvious and trivial maybe, but at least for me, it was helpful to see the tangible reality that all this programing stuff we’re working on every day is very valuable in the real world. It’s so easy to get lost in the code and the drive to build a solution, that the end goal is forgotten.
Maybe forgotten is too strong, but the reality of working for a real company can be hard to grasp, or just a distant imagined hope. Either way, walking through a tour of a place that does hire Iron Yard grads made it that much more real.
Thats a good thing. And a good feeling.