Installed Ecto

ecto is a feature-rich desktop blogging editor for MacOSX. With ecto, you can easily publish to a wide range of weblog systems, such as Blogger, Blojsom,Drupal, MovableType, Nucleus, SquareSpace, TypePad, WordPress, and more.

Welp, I finally did it. I bought a 15″ MacBook Pro on Thursday. My brother-in-law, Justin, picked up the 13″ MacBook Pro. We’re both new to the Mac OSX platform (first Mac purchase) though we both have iPhones.

First impressions

Apple Store
First of all, the apple store was awesome. Though I had to wait in a queue to find a salesperson to help me buy, the guy there was very helpful. It was cool to see how clean and simple the store was. I haven’t felt a smidgin of buyers-regret, though I have been thinking about this purchase for a very long time.

Laptop Physical Design
I decided to go without the anti-glare or higher resolution screen. I don’t seem to notice the difference. The 15″ screen is plenty large for me. I probably would have been fine with the 13″ screen, but then I couldn’t have picked up the Core i5 processor that allows for 4 concurrent threads.

The unibody design feels very sturdy and simple. It adds to my impression that this is a well-designed machine. It feels a little more industrial to me, probably because the body is made out of a solid piece of aluminum. The only downside that I see is that underneath the trackpad there are two sharp corners.

The keyboard feels solid and the keys are just at the right pressure. I like the way that they click and it’s nice to have a lights under the keys. The trackpad works great. It’s a bit revolutionary to have a multi-touch trackpad, especially with the support for gestures. I’m still getting used to not having a home or end key. I love the power cables and the magnetic connection that separates easily. Such detail everywhere.

Software
I have only touched the surface thus far, but I am finding most of the operating system’s features are intuitive once I find out where they are. Mail, Contacts and My Calendar all synced to Google for domains with almost no configuration (just username and password).

What’s next
I have a lot of software to install. Thus far, I have installed:

• homebrew
• Skype
• Dropbox
• iWork
• Tweetie
• GIT
• xCode

….more to come?

LOST, how I will miss you! To bid you adieu, I offer you my final creation for the finale tonight. The LOST Hatch Terminal. Thanks to Adam McCrea for your help unbenkownst.

NOTE: just enter in the “numbers” every 108 minutes or some really, really bad things might happen.

In case you forget, those numbers again are:

4 8 15 16 23 42

Good Luck, Desmond! I’ll see you on the other side.

p.s. The LOST Terminal looks best in Firefox or Safari. Sorry Internet Explorer

Tonight at the Columbus Ruby Brigade meeting, I gave part two of my “Core of the Core” speaking series.

Part two was on Reflection in Ruby.

Core of the Core: Reflection Presentation

Here is the presentation from my Class Class Talk at the Columbus Ruby Brigade tonight.

I thought it would be good to write down a few of my thoughts from CodeMash before I forget about it. There’s certainly more that impacted me, but something is better than nothing.

Pre-Compiler: Test Driven Development: From Concept to Deployment by Leon Gersing

Leon did a great job of somehow getting 50 people in the room to contribute to the same project. I was also amazed that the same number of people were able to share “what they did yesterday, what they are going to do today, and any blockers” in under 15 minutes. It was actually closer to 8 minutes on a few of the stand-ups.

I came away with some more GIT experience and a better idea of how to run an agile team. I liked the idea of starting from story cards and decomposing them into tasks and then allowing them to be spread out amongst the crowd. The one thing that was a little haphazard was the coordination of connected tasks.

The Not-GIT Talk by Jim Weirich

Jim is definitely one of my A-List speakers. He always prepares so well, knows his stuff, but also knows how to communicate it so dummies like me can understand it. I loved the way that he built up a so-called source control system from scratch (conceptually), solving problems along the way. This is top-of-the-line material. Oh, and you can see his presentation at the Pragmatic Programmer’s store in a screencast format.

NoSQL: Death to Relational Databases by Ben Scofield

There are a lot of non-relational databases. Need to explore them on my own to discover pros and cons of when they are beneficial and non-beneficial.

Ben encouraged us to start with a non-relational database from the beginning of a project to see how you would do things differently. He also mentioned the idea of polyglot persistence, that is having many different storage means for different purposes. This could be an interesting idea to explore as well

The Five Habits of Successful Lean Development by Mary Poppendieck

Purpose, Passion, Persistence, Pride, Profit

Mary gave a lot of examples of how these P’s play out. Persistence stuck out to me the most. She asked the question “What makes people really good at what they do?” The answer she gave was deliberate practice, and expert performance over a long period of time (10 years or 10,000 hours). This corroborates what Malcolm Gladwell talks about in Outliers.

1. Identify a specific skill that needs improvement
2. Devise (or learn from a teacher) a focused exercise designed to improve the skill
3. Practice repeatedly
4. Obtain immediate feedback immediately and adjust accordingly
5. Focus on pushing the limits and expect repeated failures
6. Practice regularly and intensely, perhaps three hours a day.

User Stories: Closing the Agile Loop by Barry Hawkins

You’ll never be as ignorant while building software about what is required for a project then when you negotiate the contract of what is in scope.

Treat a User Story as a placeholder for interaction, not a substitute for interaction. Here’s how User Stories differ from a Use Case.

• Smaller in Scope
• Not permanent artifacts
• Too brief to stuff with UI requirements
• Focus on functionality
• Facilitate iteration planning
• Analysis catalyst, not an analysis product

A User Story follows a format such as

Description of what’s needed

As a ________ User, (who is doing the action)
I want to ___________ (what do they want to do)
so that ______________. (to clarify the purpose and business value)

Conditions of Success (Acceptance criteria)

Scenario: _________
Given _____________
When I ____________
Then _____________

I’m electronifying my notes from conferences and such. Here’s my notes from Jim Weirich’s SOLID design principles in Ruby talk from eRubyCon 2009.

1.) Single Responsibility Principle
a class should have 1 reason to exist
describe the purpose of your class in a single sentence (you shouldn’t need and/or)

2.) Open/Closed Principle
you should be able to extend a class’ behavior without modifying it

3.) Liskov Substitution Priniciple
require no more, promise no less

4.) Interface Segregation Principle

5.) Dependency Inversion Principle
depend on abstractions, not concrete-tions

** Note that my notes are a little bit shotty, because the days prior to the conference I was totally totally strapped at work and thus rest-deprived.

Here are a few keybindings to help navigate in less

space | forward 1 screen
b | back 1 screen
Enter | forward 1 line
k | back 1 line
g | home
G | end
/text | search
n | next search
N | reverse next search
q | quits
v | open