The following Tweet from renowned front end developer, Noah Stokes really caught my eye the other day:

We have a Bootstrap Generation of folks coming up who have never learned basic positioning in CSS. Learn the fundamentals first, then a FW.

— Noah Stokes (@motherfuton) October 27, 2015

In the Firehose Project, one of the major things we learn about front end design is to use the Bootstrap Framework. Going into the course, I had heard a little and read a little about Bootstrap, mostly negative. The main complaints: all Bootstrap websites look the same and that Bootstrap comes with a ton of bloat. I believed that until I started using Bootstrap, which then lead me to realize that Bootstrap made designing good looking websites incredibly easy. In fact, I used Bootstrap for this website to help out with the layout.

What Noah had to say really got me thinking, though. I don’t really know much about CSS positioning, and that’s a problem. I also didn’t really know where to start looking, so I thought I would ask the master himself:

@jonathanpike I sure do :D https://t.co/EMoCkU7YG7 https://t.co/HvetuXiRAq

— Noah Stokes (@motherfuton) October 29, 2015

Aside from the resources from A List Apart that Noah linked to, I took it upon myself to research CSS layout and positioning, since it’s really a core competency of a web developer. I wanted to share a few resources that I found with you that I thought were really great:

• Learn CSS Layout: This is a fantastic tutorial that goes over CSS layout fundamentals in an easy-to-digest way. While there are only 19 “lessons”, there’s a ton to learn (and I learned a ton!).
• CSS Tricks Guide to Flexbox: One of the coolest new-_ish_ CSS layout techniques is called Flexbox, and this guide goes deep. I’ve used Flexbox positioning in a few projects and I can say with certainty that it’s easy to use (and that makes me happy).
• What the Flexbox?!: On the same theme, Wes Bos put out this great, free video course explaining all sorts of cool Flexbox tricks.

I still think that Bootstrap is an incredibly useful tool, but the fundamentals are fundamental for a reason. I think that this article from H. Alan Stevens does a really great job of explaining what Bootstrap is good for, what it’s not good for, and some best practices for using it.

In doing my research, I also came across Pure, a seriously tiny group of CSS components that help with rapid development of responsive web projects from (wait for it…) Yahoo. While Pure would obviously be subject to the same criticism that Bootstrap does with not teaching you as a developer how to CSS, it does solve the bloat problem. Worth checking out!

I have heard it said¹ that one is not a true Rubist until they learn Enumerable. To try and document what I’ve learned and keep it in my head, I am going to explain what I’ve learned here.

Today’s method: Map (or Collect, if you’re so inclined).

Let me preface the discussion of Map/Collect with a few notes:

1. There is some distinction between the Enumerable module and Enumerable methods in other classes, such as array. An explanation can be found in this Stack Overflow post. Essentially, Enumerable objects need to call a function to get the next element (typically each), and Arrays are the most common collection, so Array#Map is optimized for performance. I’m going to be explaining the Array implementation of Map/Collect

2. Ruby is awesomely friendly to programmers, and so a lot of methods are aliased to fit with whatever convention the programmer used prior to coming to Ruby. Another example is Inject/Reduce, which I will go into in a later post. Suffice it to say, you can use either Map or Collect and you will get the same result.

So, what is Map used for? Map is designed to iterate over an array and change each value. Take the following code, for example:

numbers = (1..10).to_a

# With Each and Push
new_numbers = []
numbers.each do |number|
  number = number ** 2
  new_numbers << number
end
# => [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

# With Map 
new_numbers = numbers.map { |number| number = number ** 2 }
# => [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

I created an array of numbers from 1 - 10 on line 1, and I want to square each number in the array. You can see how Map does the same thing as looping over each number with each, squaring the number, and then pushing it to a new array. Map allowed me to compress 5 lines of code into 1.

Map does not modify the original array. If I did not assign the result to new_numbers, numbers would still be an array from 1 - 10. If you would like to modify the array in place, you can use Map!².

One novel way of using Map that I’ve found is to use it to change the type of each item in an array. For example, if I have a string of numbers (str) and I would like to work on it as an array of integers, I would simply use the following: str.split(“”).map(&:to_i)

Super easy!

Map, like all of the Enumerable methods, is insanely useful, although complicated to get the hang of. Go and learn it by practicing!

An old but good article from Signal V. Noise, the blog from the Basecamp folks. While Jason Fried singles out Photoshop, this clearly applies to the design tools that I’ve seen recommended a lot recently: Sketch 3 and Balsamiq. Both of these apps look really great at what they do and I’m sure there are lots of really fantastic uses for them.

The main point I take from Jason’s article is that wireframes are useful, but creating them digitally without using HTML + CSS creates extra work for you later and doesn’t allow for rapid sharing of evolving designs in teams. Most importantly, wireframes don’t allow for user interaction. While I’m new to designing websites and apps, I tend to agree with his perspective.

I’ve put my money where my mouth is on this one: for my upcoming projects (and for the design of this blog), I’ve wireframed on paper first, and then started plugging away in HTML and CSS. This has really helped me learn HTML and CSS better, and I imagine I’ll only get faster as I practice more.

Recursion is a topic that has greatly confused me since I learned about it. After all, the joke goes “in order to understand recursion, you must understand recursion”. I knew that, stated simply, recursion is calling a method from within itself, but I had no idea how to implement a recursive method or how a recursive method worked. That all had to change when I was required to write a recursive function to return the fibonacci number given an index for one of the job prep challenges in the Firehose curriculum. Here is the code I came up with:

def recursive_fib(num)
    if num <= 1
        return num
    else
        answer = recursive_fib(num - 2) + recursive_fib(num - 1)
    end
    
    return answer.abs
end

def iterative_fib(num)
    fib = [0, 1]
    
    (num - 1).times do 
        nextnum = fib[-2] + fib[-1]
        fib << nextnum
    end
    
    fib.last
end

Having begun learning programming seriously with Python (an object-oriented language), my mind seems to work naturally in loops. As such, the iterative solution was much easier to conceptualize (ie. initialize an array for the fibonacci numbers, create a loop that executes n - 1 times to fill out the array, and then return the last value) and much easier to write.

The recursive solution, as I figured out, works because of how fibonacci numbers work: the next number in the sequence is the sum of the two previous. And so, the recursive solution sums the fibonacci number of the previous 2 indices and returns the answer. After figuring it out, this solution seems trivially easy.

That explanation leaves something to be desired, though: how does the recursive method know what the fibonacci number at the two previous indices is? How does it know the fibonacci sequence at all? That’s the mystery of recursion.

After reading a fantastic article from the University of Maryland Computer Science Department, I believe I have a good enough grasp on recursion to answer that. The key to understanding recursion is realizing that you require two parts, at minimum: a base case and the recursive call. In the fibonacci sequence problem, the base case is line 2 – if num (the index) is less than or equal to 1, the fibonacci number you are looking for is 1. Everything stems from the base case, generating each successive fibonacci number by running through the base case up to the asked for index. Breaking the problem into its smallest element and then calling that element over and over again until you get the desired result is recursion.

The point of this exercise, in part, was to show that recursion, in some situations, can be extraordinarily inefficient. The iterative solution performs many times faster than the recursive solution, and given a high enough index, the recursive solution will actually cease to function (it runs out of memory). It’s an eye opening exercise and a very different way of thinking.

I still prefer iteration, though!

Amidst the roiling debate of whether FogBugz lost to JIRA, one thing has become really clear to me: there has never been a better time to be a developer. Me of a few months ago would recoil and ask “but aren’t all the good, easy, profitable ideas already taken, just like every good domain name/username/gmail address/etc. is taken?” That’s where I believe I was wrong.

While I don’t have the perspective of developing software for years, Joel Spolsky, author of the popular programmer blog, Joel on Software, and CEO of Fog Creek (the makers of FogBugz), gave a history of the company on that Hacker News thread that served to change my mind dramatically. Here’s a quote:

I wanted to make software development better for programmers. When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000). There was almost no thought around how software should be developed. Companies that scored high on the Joel Test were almost unheard of.

That’s just 15 years ago! He goes on to say that the reason he started blogging and the reason he started Fog Creek was to make things better for developers, both projects can be counted as successes (what programmer hasn’t read Joel’s blog, and the current debate is about whether FogBugz has “lost” to JIRA… but we’re still talking about it!).

I don’t believe Joel’s perspective speaks for the entire industry. I have heard anecdotes about places like Bell Labs, which gave us computing gems such as C and UNIX, which clearly were havens for programmers in their day. However, most organizations can’t thrive on research and new technology, and most businesses use technology as tools to help them get their real work done (ie. line of business apps). It is clear that things have changed for programmers in a good way.

The modern developer has a vast array of well-thought-out and useful tools at his or her disposal. Consider all of the friendly, full featured high-level languages like Ruby and Python we have to work with. And the wide variety of awesome text editors for writing beautiful code. And what about source control? That makes everybody’s life easier!

Thinking specifically about web development, we have all sorts of frameworks that allow us to build applications faster and with less overhead. And then there are the libraries that save us tons of time implementing features ourselves. We even have ways to make sure that we are all developing on the same platform, to make it easy to share code amongst one another.

Being new to this game, I’ve hardly had the chance to dip my feet into the warm, warm water of being a developer. We are far from all of the good ideas being taken, and all of these tools just make it easier for us to build out those good ideas.

I’m so stoked to be a developer right now.