If I come from a world with React and JSON-API but then am working on a project that is vanilla Backbone.js and Twitter Bootstrap, what problems does React solve for me that I'm not aware of until I have to solve them in my current project? In other words, what complications of modern web-apps (like

October 29, 2015

First of all, how lucky you are that you get to work with The New Hotness most of the time!

To your question-- the most important thing about React is not the framework itself but the patterns, such as:

- Declarative over imperative views (i.e. your code is what the rendered component looks like, not step by step instructions for building it)
- One-way binding and data flow (data rolls downhill from parent to child only)
- Very little mutable shared state between components (avoiding joint custody/multiple write locations for objects)
- Composition over inheritance as the extension mechanism. DOM patching is right out.

You can implement the same patterns in other frameworks. ask.fm is bad for sharing code, but here are some rough ideas for your backbone case:

- Build on Backbone.View.render so each view doesn't do its own imperative DOM math. Make it so subclasses implement a declarative "template" method instead.
- Let Backbone.Component be composed-- i.e. should have a "children" attribute that represents components nested under this one. Expose that to the template.
- Don't pass data "up" from child views to parent views. Avoid upward communication when you can, and use events when you can't.
- Avoid using selectors anywhere in your code other than your default .render implementation.

In what instance would it be a good idea to overwrite the `class` method on a Ruby class? I.e. add a `def class` to your class definition.

October 13, 2015

Basically never in application code. You have to think about what the next programmer or gem would expect. Yes, yes, it is ruby and you can redefine everything. However, this is so rarely done, no one would know to look for it.

There's a bigger concern though. Why would you _need_ to override `class`? You _are_ using duck typing, right?

(There are edge cases of course. It is ruby, so you _could_ implement/extend your own class system dynamically and I guess you might want to override `class` then).

Are you an early bird or a night owl?

September 30, 2015

Yes.

What tools, like git blame and linters, are absolutely necessary and/or incredibly helpful for a developer working on an existing codebase?

September 23, 2015

* The most important thing is having someone you can ask questions. As developers, we always want to go solo and use technology to solve human problems, but "the last person who worked on this" is your #1 resource.

* Tests. If you are diving into an existing codebase, make sure you know what tests are there and that you can get them to pass before you tinker. If there aren't enough tests, write more before you tinker. It is still the best way to avoid creating regressions.

* I like having a linter configured for each language used on the project, with the settings adjusted to match the existing code style. If the existing code style inconsistent, you can at least clean as you go and avoid making things worse. Beyond style issues, you'd be surprised how often linters catch actual logic errors in code.

* Continuous Integration and Continuous Linting with notifications-- because if you are the only person honoring the tests or the lint rules, you are swimming against the current. We like codeship for CI, and I built a system called Linton https://github.com/prehnRA/lintron that we use for continuous linting.

* I want to start using visual diffing to catch style and layout regressions. The idea is that your tests keep screenshots of your application each time the tests run, and notify you when new screenshots are different than the old ones. I don't have this set up yet, but I'm thinking about figuring out how we can integrate something like https://github.com/Huddle/PhantomCSS into our tools.

* Two random "hidden gems": https://github.com/preston/railroady Railroady for visualizing database layouts. "rake notes" for grabbing outstanding FIXMEs, TODOs, etc.

What exactly is MapReduce algorithm, what does one look like, and what kind of advantages do they have?

September 22, 2015

Map/reduce is a way of thinking about an operation that you need to perform by breaking it into two pieces-- a map phase and a reduce phase. The map phase collects, groups and sorts the information needed. The reduce phase summarizes the data after the map phase is completed.

Let's say you wanted to calculate the average age of employees in a bunch of industries from a data set. Your map phase would receive a set of employees with their industry and age. For each employee, it would append their age to an array of ages for that industry (basically, the map phase receives an array of employees and returns a hash from industry => Array). The reduce phase takes each industry bucket in turn and averages all of the elements of the array (it takes the hash from the map phase and returns a hash from industry => average age). In turns out that there are a lot of calculations that can be broken up in this manner.

Why would you want to separate your algorithm out like this? Map and reduce are both easily parallelizable and distributable operations that requires very little information sharing. Each map or reduce worker only needs to receive partial input (i.e. part of the hashes outlined above) and can still do meaningful work. This means if you have big data sets you throw a lot of compute power at your problem and get faster answers.

If you could put any developer on the $10 bill, who would it be?

September 18, 2015

I nominate the only software engineer who, as far as I know, has saved a moon mission.

Margaret Hamilton https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist) was the Director of Apollo Flight Computer Programming. She designed the ultra-reliable Apollo flight computer software which guided the lander to the surface of the moon. The system was resilient and self-correcting against a number of faults, including cycle stealing.

This resilience came in handy when a faulty checklist lead to the landing occurring with a radar system in the wrong state:

"Due to an error in the checklist manual, the rendezvous radar switch was placed in the wrong position. This caused it to send erroneous signals to the computer. The result was that the computer was being asked to perform all of its normal functions for landing while receiving an extra load of spurious data which used up 15% of its time. The computer (or rather the software in it) was smart enough to recognize that it was being asked to perform more tasks than it should be performing. It then sent out an alarm, which meant to the astronaut, I'm overloaded with more tasks than I should be doing at this time and I'm going to keep only the more important tasks; i.e., the ones needed for landing ... Actually, the computer was programmed to do more than recognize error conditions. A complete set of recovery programs was incorporated into the software. The software's action, in this case, was to eliminate lower priority tasks and re-establish the more important ones ... If the computer hadn't recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful moon landing it was."
—Margaret Hamilton, Director of Apollo Flight Computer Programming MIT Draper Laboratory, Cambridge, Massachusetts, "Computer Got Loaded", Letter to Datamation, March 1, 1971
Now, that is some software engineering.

The Apollo flight computer program also gave us many modern software engineering practices, for example automated testing.

Plus, "Hamilton is on the $10 bill." would still be true, saving who knows how much in encyclopedia editing and printing costs.

Robert Prehn

Nothing here yet