What I have been working on (UPDATE AFTER THREE YEARS)

Whelp, this blog (The Coding Diaries) hasn’t been updated in three years! I’ve started chronicling some code notes on codenotes.tumblr.com, which you can follow if you are so inclined.

I am still a developer at ActionKit, campaigning software for large progressive non-profits like MoveOn.org, Indivisible, ONE, the ACLU, and 350.org. I know a bit more than front-end (Python, Django, SQL) now.

In my free time, I’ve been growing a global community of independent code learners who enjoy sharing knowledge and helping each other become better software developers, called CodeBuddies. The project is open-sourced and also has an Open Collective.

It’s a great community full of amazing contributors; more about them here. Join us on the Slack or on the forum, too; I’m @linda there.

Notes from Strange Loop

The conference was excellent. You can watch all the conference talks here!

How to create multiple forks of a git repo

Thanks to https://adrianshort.org/create-multiple-forks-of-a-github-repo/ for the instructions.

In summary (using Telescope, an open-sourced project on Github, as an example):

1. git clone https://github.com/TelescopeJS/Telescope.git cb2

2. git remote rename origin upstream

3. git remote add origin https://github.com/lpatmo/cb2.git

4. git push -u origin master

Day 9: #100daysofcode

• You can search by regex in sublime text!
• SASS Guidelines http://sass-guidelin.es/ is a good resource.

Day 8: #100daysofcode

I did not know rewriting <pre></pre> so that I could have more control over each of the form elements was as easy as transforming it into:

with <pre></pre> and <pre></pre> and <pre></pre> as variables. :D

This post is a part of the #100daysofcode challenge.

Day 7: #100daysofcode

• Python uses "classical inheritance. JS uses "prototypal" inheritance.
• In python, you have an init constructor which generally contains some methods. In javascript, any function can be constructor by putting new in front of the function call. Make a method available to every instance of this javascript constructor by adding it to the prototype property of the constructor.

class Example(object):
    def __init__(self, args):
         self.args = args

     def example_function(self):
         #something to self.args

f = Example(data)
f.example_function()

//python

function Example(args){
this.args = args;
}

Example.prototype.example_function = function() {
 //do something to this.args
}

f = new Example();
f.example_function();

//javascript

• In python, functions and methods are different types.
• How to make an object inherit from another in javascript:

function Base() {
   console.log('something');
}

function Derived() {
   console.log('something2');
}

Derived.prototype = new Base();

• How to make a class inherit from another in python:

class Base(object):
   pass

class Derived(Base):
pass

Source: Matt Chisholm (https://blog.glyphobet.net/essay/2557)

This post is a part of the #100daysofcode challenge.

Day 6: #100daysofcode

• It's common to use adjectives as the names for decorator functions.

Decorator functions can pass in more than just simple value properties. They can also pass in functions.

• "Functions in Python cannot be anonymous, and function declarations are not expressions, so they cannot be defined and used on the same line." (Helpful article: difference between javascript and python)
• Tip: move functions outside of constructor function so that the function is not invoked every time an object is instantiated. For example:

var Car = function(obj, loc) { 
var obj = {loc: loc };
obj.move = move;
return obj;
}

var move = function() { 
    obj.loc++;
}

• Decorators take in another function or a class as an argument and return a modified function or class.
• The reason why most JS libraries are wrapped in an anonymous function: it protects the contents of the library from interference by other .js files.
• In javascript, variable hoisting happens. That is, a variable is defined ("hoisted") to the top of its scope (e.g. if var a = 5 on line 5 inside a function, it would be as if var a; on line 2).

In python, there is no variable hosting, so an identifier would not exist until the interpreter reached the line of code where it was defined. (Source)

–
Q: How do I simply the following?

var amy = {loc: 1}
amy.loc++;
var ben = {loc: 1}
ben.loc++;

A:

var move = function(car) { 
   person.loc++;
}

var carlike = function(obj, loc) {
   obj.loc = loc;
   return obj;
}

var amy = carlike({}, 1);
var ben = carlike({}, 2);
move(amy);
move(ben);

==============

This post is a part of the #100daysofcode challenge.

Day 5: #100daysofcode

Today I Learned: If you need to do a lot of relational queries with your data, try not to use mongoDB. (More Info) + overheard from engineers' experience at a tech meetup

This post is a part of the #100daysofcode challenge.

Day 4: Random #100daysofocode

• will wrap the form in <p> tags. (Django)

This post is a part of the #100daysofcode challenge.

Day 3: Random #100daysofcode

• white-space: pre-wrap preserves white spaces and breaks lines at newlines. (CSS)

*You can index your models with db_index=True (reference)

• You can give your model metadata by adding class Meta. Example from the official docs:

  from django.db import models
  class Ox(models.Model):
    horn_length = models.IntegerField()
  
    class Meta:
        ordering = ["horn_length"]
        verbose_name_plural = "oxen"
  

Metadata options can include db_table, ordering, and verbose_name_plural. (reference)

• What is the difference between OneToOneField and ForeignKey?

This post is a part of the #100daysofcode challenge.

100daysofcode Challenge Diary Log

##Day 2!

• In a tuple such as:

    GENDER_CHOICES = (
      ("M", "Male"),
      ("F", "Female"),
      ("?", "Unknown")
    )
  

  … within models.py, the first value is written into the database. The second value is the value that is displayed for the user.</li>

• After writing up models.py, you need to run these two migrations to sync the database:

  python manage.py makemigrations academy
  python manage.py migrate academy
  

• Adding the -p flag can make TWO directories! For example:

  mkdir -p project/subdirectory1/subdirectory2
  

• By default, BASE_DIR is set to the root of your project file — the same spot where you can find manage.py.
• open(): https://docs.python.org/2/library/functions.html#open
</ul>

*csv.DictReader(open(csv_file)) will return a list with each row in the file as a dictionary.

• OMG THIS INSIDE admin.py IS MAGIC:

from django.contrib import admin
from academy.models import Invite

class InviteAdmin(admin.ModelAdmin):
    list_display = ("name", "branch", "gender", "date_of_birth", "race")
    list_filter = ("branch", "gender", "race")
    search_fields = ("name",)

admin.site.register(Invite, InviteAdmin)

*If you just want to ‘deploy’ a site so that it’s available to other users in your intranet network (e.g. other people in your office), try this: 1) Find your IP address by typing ifconfig into your command line. 2) Run $ python manage.py runserver 0.0.0.0:8000 in your terminal. 3) Paste in http://[IP ADDRESS]:8000/admin/ into your browser. Theoretically, this should work, but it did not work for me just now. :(

• Every time you change your models, in newer versions of Django, run something like: python manage.py makemigrations appname. Every time a migration is run, a file will be added to /appname/migrations. Next, you have to actually run the migration: python manage.py migrate academy.
• list_display is awesome. So is list_editable.

Thanks much to http://first-django-admin.readthedocs.org/en/latest/ for the surprisingly straightforward and short django tutorial.

This post is a part of the #100daysofcode challenge.

##Day 1: Random Note to self: if a div inside a div isn't recognizing the parent div as a parent when it's set to position: absolute, it's because the closest parent needs to be set to position: relative. Otherwise, it'll default to position: static. (CSS) Meteor.startup() { } is sort of like $(function() {}); except we use it with meteor. (MeteorJS) Adjust the height of a textarea with its content:

$('textarea').css('height', 'auto'); 
$('textarea').height(this.scrollHeight);

If you want the ability to write markdown inside your WordPress posts, see:
http://www.elegantthemes.com/blog/tips-tricks/using-markdown-in-wordpress. (I decided on using the PrettyPress Editor.) </li>
• Note: to pull from a branch inside an upstream repo… git fetch upstream branchname and git merge upstream branchname
• If I notice that there are elements inside view:source but can't find it inside the browser elements tab, chances are it's because there was a .remove() put on the elements. (JS) localStorage is nice and lighter weight than cookies. Intl.DateTimeFormat().resolvedOptions().timeZone ? Intl.DateTimeFormat().resolvedOptions().timeZone returns the users's timezone! However, this is currently supported on only very limited modern browsers. (JS) This post is a part of the [#100dayosfcode](http://www.thecodingdiaries.com/the-100daysofcode-challenge/) challenge.

The #100daysofcode Share-One-Thing-You-Learn Challenge

I am pretty sure I am a better developer than I was 100 days ago, but some days I look at my coworkers’ commits, or think about all the frameworks I still don’t have great experience with, and wonder about the actual rate of my progress.

Wouldn’t it be cool if more people shared their small knowledge victories, and were able to point back to those archives and say “this is what I’ve learned”?

So here’s the challenge:

• Write a short blog post (or tweet/instagram) about ONE NEW THING you learn that’s code-related — no matter how small — each day. It could be a code snippet. It could be a summary of a stackoverflow answer. It could be a sentence referencing an “aha!” moment. #100daysofcode
• Do it for 100 days.

Then, if you’re interested in joining a 24/7 chat of independent beginners and experts helping each other learn coding topics faster, check out the codebuddies.org slack chatroom — and share the link to your #100daysofcode blog post, tweet, or instagram in the #100daysofcode channel. You can invite yourself to the chatroom here: http://codebuddiesmeet.herokuapp.com.

You can start the challenge any day.

Credit goes to https://thegreatdiscontent.com/100days for the inspiration behind this challenge.

SASSConf NYC Reportback (2014)

I went to SASSConf (my first SASS Conference!) in October 2014 and had a blast. The conference — organized by @itsmisscs and @Snugug and supported by a team of volunteers — had probably the most robust agenda in a conference I'd seen for a while.

SASSConf took place at convenient time for me — right when I was just getting into the meat of refactoring some CSS into SCSS for a larger redesign project at work.

The first day of the conference was set aside for scheduled speaker talks, the second day was set aside for two back-to-back workshops (you could choose from one of two during the morning and afternoon), and the third day was set aside for an un-conference. A lot of care was put into everything from speaker accommodations and food to technical learning opportunities. Oh — and the after-party on Friday encompassed a karoake and open bar that took place on a boat. A boat.

Before I get into more beautiful boat pictures, though, let me recap my main three technical takeaways from the conference:

1. What's the point? Don't Repeat Yourself. (DRY)
Instead of writing straight CSS in a single file for a single component, organize your CSS into different files based on meaning (e.g. the names of your partials can be _buttons.scss, _colors.scss, _layout.scss), and use variables and nesting to keep the CSS organized nicely. Doing this helps get rid of repetitive styles.

I also learned that people were actually using different versions of SASS — i.e. there was "rubysass" versus "libsass." Libsass is a little behind rubysass in its development, but still comes with some advanced features such as maps and lists. There are also a ton of supplementary tools that some SASS developers use such as Compass, Bourbon (a mixin library), grunt.js, gulp.js, etc.

However, my takeaway was that it wasn't important to go out and use every SASS feature or accompanying tool available. You should use SASS in a way that makes sense for your project, keeping in mind that it's supposed to _help _you write CSS more cleanly and follow the DRY way of thinking.

2. Mobile first!

I asked some conference-goers — including @jina, a co-organizer for one of the workshops — what their opinion was of using max-width vs. min-width media queries, and basically got a unanimous response in favor of mobile first. Min-width media queries it is, then.

In mobile first, you're developing for mobile devices from the start — making sure your website looks great on phones and tablets — before adding CSS styles that change the layout of the page as you stretch the page. Basically, one of the advantages of "mobile first" is that you don't need to specify a breakpoint size to target mobile devices only.

(Side note: I'm super glad I hopped on the mobile-first train, since I ended up suggesting it to my coworker, and we made a decision to go with it, and it made every part of the redesign project a lot easier.)

A couple of other tips I picked up re: writing CSS for the responsive web:

• Use ems instead of pixels (http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/). This might give you problems with IE8, but there are great libraries out there that help fix problems. UPDATE: Thanks Ana Tudor for pointing out that this issue isn’t really an issue anymore! The CloudFour blog post was published in 2012.
• Use modernizr, a javascript library that will do a quick check for what things are supported.
• https://github.com/jina/refactoring/blob/master/examples/named-media-queries.scss has a a great example of a media query mixin.

$bp-tiny: 300px;
$bp-small: 500px;
$bp-medium: 600px;
$bp-large: 800px;
$bp-larger: 1000px;
$bp-full: 1200px;`

@mixin breakpoint($media) {
@if $media == bp-tiny {
@media only screen and (min-width: $bp-tiny) {
@content;
}
}
@else if $media == bp-small {
// small and medium are 1px smaller than their previous variable
@media only screen and (min-width: $bp-small - 1) {
@content;
}
}
@else if $media == bp-medium {
@media only screen and (min-width: $bp-medium - 1) {
@content;
}
}
@else if $media == bp-large {
@media only screen and (min-width: $bp-large - 1) {
@content;
}
}
@else if $media == bp-larger {
@media only screen and (min-width: $bp-larger - 1) {
@content;
}
}
@else if $media == bp-full {
@media only screen and (min-width: $bp-full - 1) {
@content;
}
}
}

For a quick demo on use cases, this is what the CSS class .sidebar using the breakpoint mixin looks like when compiled: http://sassmeister.com/gist/ea430284384722b8f850

3. Your style guides should be "living."
My takeaways:

• "Static (un-automated) documentation is a lie waiting to happen. Live style guides are great." – anonymous.
• Basically, the argument for "living style guides" (style guides that developers don't manually have to update, because it updates automatically with CSS commits) is that style guides are fluid and will change. The design will change.
• Meetup.com has an example of a robust style guide: github.com/meetup/meetup-swatches
• https://github.com/hagenburger/livingstyleguide-workshop is a ruby gem that lets you easily create a style guide from your existing SCSS files using YAML/Markdown-type syntax.
• KSS is another popular live style guide creation tool.
• With style guides, adoption can sometimes be hard. You need to convince developers to use it and maintain it.
  HELPFUL REFERENCE LINKS
  http://www.anthonydispezio.com/sassconf2014
• Lots of great examples of advanced uses of SASS — with links to SassMeister, the JSFiddle-equivalent for CSS.

https://github.com/jina/refactoring/

• Lots of great examples from this repo. The media query mixin above is inspired by one of the code examples here.

Only ~100 people attended the conference. Although this was a relatively small conference, it was clear that SASS was getting more and more widely used. According to a javascript developer I talked to, last year at CSSDevConf over half the talks were about SASS.

OTHER NOTES I JOTTED DOWN

• Mathematicians have done very cool animations using pure CSS keyframes/SASS.
• Hampton (@hcatlin) is the creator of SASS and is mostly working on upgrading libsass (https://github.com/sass/libsass) to the same level as RubySASS (https://rubygems.org/gems/sass), which has a few more advanced features.
• More advanced features include: SASS lets you iterate over numbers, lists, and maps. You can also use @for, @each, and @while.
• "Pairing between a designer and a developer is awesome because you're learning from each other." – @jina (I say this from experience: I totally agree!)

MORE PHOTOS FROM SASSConf 2014

I won a book in a random lottery on the third day (unconference-style)!

Goodie bags for the attendees.

Speakers on the first day.

Guess where the conference was hosted — at Scholastic Inc.! The last time I'd been in the building was 10 years ago, when I'd won a writing award for a short story as a teenager.

Beautiful SASSMeister projected on a screen.

Between decks on the boat. Filtered.

Is that the Manhattan Bridge?

On the road to competency – two tips

Last year, jumping from an HTML/CSS/JS mindset to working with full-stack apps was confusing. A single rendered page on a full-stack (e.g. Rails or Django or MeteorJS) app could be drawing in code from *multiple* files in different folders. I was often confused about where everything was located.

Eventually, my co-worker Tim gave me two great tips, which made a *huge* difference in my ability to debug problems in more complicated apps.

Tip #1: Install and use the silver searcher (https://github.com/ggreer/the_silver_searcher). Once I started learning how to search for keywords by typing in “ag [keyword] -C5” or “ag [keyword] -l” in my terminal, I was able to figure out much more easily the files that certain bugs were located.

The first example returns to you the file paths and line numbers where the keyword match (as well as 5 lines before and after the matching row for context).

The second example returns the file paths and line numbers that match the keyword, but shows up as a list, and does not include any of the code or context. Using the “-l” search parameter is helpful if some of your search returns happen to be one long string.

Tip #2: Use find . -name “keyword”

This command searches for file names that match a specified keyword. Helpful if — for example, the word “apple” is the name of a file, but is never within the contents of any of my code.

=====

Interesting to reflect that in addition to being competent at “googling” for solutions on the internet, part of being a developer is becoming competent at searching for things in your own codebase.

Learning TDD

Just discovered https://github.com/gregmalcolm/python_koans by way of someone who proposed a CodeBuddies hangout on this tonight.

It’s a terminal “game” that you run while editing files to make the tests pass and it’s surprisingly fun/a good review.

Steps for getting started:
1. git clone https://github.com/gregmalcolm/python_koans.git
2. cd python_koans/python2
3. Run python contemplate_koans.py in the terminal.
4. The terminal will tell you which file in python_koans/python2/koans to open up and edit. Edit the line and then run python contemplate_koans.py in the terminal again to make it pass, at which point you’ll be pointed to the next error to fix.

SURPRISINGLY ADDICTIVE!

I recently had a coffee chat with @saronyitbarek, who swore by TDD, and a lot of what she told me made sense — i.e. the idea of outlining your steps before you start to code. We’d just installed nose at work too, so I plan to try to get into the habit of it too.

Learning to code, but feeling lost? I interviewed some experts, and here’s what I found. (Part II)

I recently had the pleasure of connecting with five talented people who had wisdom to share about their journeys into tech. I’ll let their words speak for themselves.

INTERVIEWEE PROFILES

Stephanie Chang (@stchangg) taught herself web development and hacked her way to a full-stack software engineering job at Khan Academy. She studies behavior change, occasionally pens nerdy raps, and blogs at stchangg.com.

Marcus Willock (@crazcalm) is a self-taught technologist who recently landed a QA engineering job at Adcade. When it comes to development, he is a hackathon enthusiast who tries to always have a side project in the works.

Cheney Tsai (@cheneytsai) is currently a mobile solutions consultant at Google. When it comes to development, he’s a full-stack engineer with a deep interest in UX design.

Wayne Warner (@wawjr3d) is a senior front-end developer at Bloomberg LP who’s been programming for 15 years. He blogs at wawjr3d.tumblr.com.

Nicole Bieber (@nicolethenerd) is a senior software engineer at Amplify and an instructor at the New York Code + Design Academy. She earned an SB and MEng in Computer Science from MIT.

ABOUT THE INTERVIEWER

Linda Peng (@lpnotes) is a front-end web developer at ActionKit. She recently became convinced that studying full-stack web development with strangers via self-organized Google Hangouts at CodeBuddies.org (pair programming partners!) is incredibly fun. She enjoys Harry Potter, playing violin, and collaborating with people on meaningful projects.

THE QUESTIONS

1. What’s your name, when did you first start learning to code, and what technologies are you most familiar with?

STEPHANIE: I’m Stephanie H. Chang. Because my name is so dang generic, I go by @stchangg on the internet.

I first started trying to learn how to code the summer after I graduated high school. I bought an intro to Java textbook and tried to teach myself, but got stuck after trying to get Eclipse set up on my Windows computer. When I started college a few months later, I took an introductory MATLAB programming course for engineers. I signed up for and dropped the core intro to CS course TWICE before I completed it for real, because I was so intimidated by the first week’s course load and didn’t think I could keep up. Even after successfully completing the intro to CS course and TA-ing for it, I tried to get into web development on my own and struggled to make progress, so much that I ruled out the possibility of becoming an engineer after college.

It was only after I graduated from college and worked for a while that I got a second wind learning web development and landed my current programming job. So for me, learning to program has been a long journey, filled with many false starts and many dark moments of insecurity. I’m most familiar with Python, Google App Engine, JavaScript, jQuery, Backbone.js, React, and git.

MARCUS: My name is Marcus. I first learned to code in school. I was a math major and Java 101 was a mandatory course. At the time, I hated it. Till this day, I still do not code in Java. However, towards the end of my math degree, I started to gain interest in coding, but I never had time to pursue it. A few years later, when I was in my master’s program for teaching Chinese, I suddenly had the free time to learn something new. I chose Python. I had heard good things about the language and there were no curly braces to deal with.

CHENEY: Hey! I’m Cheney and I’m currently a Mobile Solutions Consultant at Google. My first exposure to code was actually rather early when my dad made a digital card for my 4th birthday. He used BASIC in a MS-DOS environment to draw a cake and output MIDI for the birthday tune. From that moment on, I was hooked on the power that comes from teaching a computer to do things.

I was notorious in 5th grade for lugging around gigantic books that were far beyond me at the time (Visual Basic 6, Game Programming in C++, and so forth). While I never did build what I had imagined in my head (my own Pokemon RPG), it was great to start understanding how systems worked as well as to decompose gaming ROMs to modify my favorite games.

Though I dabbled in a lot of technologies, I didn’t start focusing on Computer Science and Engineering until my senior year in high school. From that point on, I found myself working in Web Development, Electronics, and now Mobile Development. I consider myself a Front-End leaning full-stack engineer given my interest in Design and User Experience, so I spend alot of time in JS as well as HTML/CSS. My scripting language of choice is probably Python though I’ve been experimenting more with Node and Go recently. Outside of web dev, I use Java for Android development and have been looking into Swift for iOS.

WAYNE: My name is Wayne Warner. I learned to code when I was about 15. I’m most familiar with javascript, CSS, and HTML. But I’ve used pretty much everything that exists: at some point PHP, C++, Ruby, VB.net, ASP.net, etc. Whatever you can think about! I work as a front-end developer now, but I’m transitioning into management.

The first thing I learned was HTML and Javascript and CSS when I was 15. Then I had an internship with a gas company, where I gained experience with VB.net. I didn’t really learn any of this in school. When I got to college, I learned computer science is a mathematical theory. I did some Java, C++, and C–, which was a language that my school created. But I didn’t learn that in a professional way. I couldn’t have taken that knowledge and transferred that into what I know now. Officially, I majored in cognitive science with a concentration in computer science.

NICOLE: Hi, I’m Nicole! I was lucky enough to be introduced to programming at the young age of 8, when a volunteer at my elementary school taught us to program in Logo. I wish I could say I caught the coding bug then, but I don’t think I quite understood at that point that I could recombine individual commands to draw whatever I wanted – I was mostly copying whole programs off a worksheet and changing a few variables to move them around or change the colors. I lucked out again when a different volunteer introduced me to programming on a TI-81 the next year, and I haven’t stopped programming since.

Today, I program almost exclusively in JavaScript, using AngularJS – but I don’t consider it my “native” programming language – that would have to be Java, which I used for most of my formative coding years. I’ve also spent a decent amount of time programming in Python. I consider myself a front-end developer these days, but that’s a fairly recent development.

2. What was a turning point/lightbulb moment for you when you first started learning?

STEPHANIE: One big “aha” moment happened when I was working on a little project to scratch an itch I had. I like making visual art and wanted 1) to learn JavaScript, 2) to learn how to work with an API, and 3) to showcase my art on my personal website. I was disappointed with many popular Flickr plugins, which to me felt too slow and over-stylized. I wanted to make a plugin that would load batches of images from Flickr in the background as the user browsed my photos.

As I worked on this project, I ventured to ask an incredibly newbie question on StackOverflow revealing my total lack of understanding of how AJAX (asynchronous HTTP requests) worked. Since all the coding background I’d had before was in Java (before Java 8), I didn’t know about callbacks and functional programming paradigms. But once I grasped the basic concepts, APIs for JavaScript libraries like jQuery and Backbone.js started making a lot more sense.

The interesting thing is that, while you might be intimidated by all of the jargon at first, if you give it some time, and just patiently and persistently explore the giant maze that is modern web programming, one concept at a time, it’ll start making more sense. It’s overwhelming at first, but it really does get better with more exposure, and to be honest, you don’t even need to know everything or even a majority of it to make significant progress.

MARCUS: The turning point in my learning of programming was when I decided to try to make a career out of it. At the time of this decision, I was not good at programming, but having a career minded mindset helped me focus on learning how to code properly. I started caring about code quality, code design, clean code, and coding practices. Completing a project was no longer good enough. I now had to complete the project and have code that I could be proud of.

I started learning python by completing the course in Codecademy and doing Project Euler questions on the side. I got so obsessed with solving those problems that I would sit in the back and code during my grad classes. After studying by myself for a long while, I felt the need to branch out and search for other people who like to code.

Being a student at the time, I began my search by looking through the student organizations on campus. The student CS organization hung out in a place called the “Cave.” That place was, and is still filled, with CS majors who have fully embraced the hacking culture. Through that group, I learned about hackathons, tech meetups, hacker schools, and a bunch of outlandish tech trivia.

In terms of languages, I am most familiar with Python. It was my first language and, because I felt a need to learn the fundamentals of Computer Science, I used python as a tool to learn everything I missed out on by not studying CS in school. I bought python books for data structures and algorithms, GUI programming, web development, object oriented design, coding cookbooks, and plenty others just so I could beef up my CS knowledge.

CHENEY: I’ve had ups and downs with learning as my interests changed over the years, but what always seems to bring me back is the satisfaction when an idea is actualized. This ranges from seeing a fellow classmate’s design project, watching one of my students successfully program their Lego robot, and even the releases of new technologies and the possibilities they bring.

WAYNE: There’s been a ton of lightbulb moments. A couple of memories stand out:
– Back in the day, when I figured out who to use javascript to do something I wanted to do that seemed really hard at the time. This was before position:fixed was possible in CSS.
– Another moment was when I made a project to learn how to code. When I was 15, I had an internship at a help desk. One of my co-workers asked: “Does anyone know how to make websites?” And I raised my hand. This was in 2001.

NICOLE: I really got into programming around the time when I was in fifth grade, at roughly the same time that I started spending a lot of time playing video games (that interest has since waned – fortunately, my interest in programming is still going strong!) It was at that point that I decided that I wanted to be a programmer when I grew up – particularly, a game programmer at Nintendo. So when the monthly Scholastic catalog came out featuring a Learn to Program Basic computer game, I had to have it – because I was going to be a programmer! Fortunately, my parents were kind enough to oblige.

One of the big questions I’d had about programming up until that point was how game programmers moved their characters around on the screen. No programming language I had seen so far had commands for “up”, “down”, “left” or “right” – and I often wondered where these missing commands were. What was the secret that I was missing? When my Learn to Program Basic software finally arrived, I found out – the coordinate system! It was so brilliant, I wished I had thought of it myself.

3. What tutorials or resources did you use when you were learning X, Y, or Z?

STEPHANIE: I worked through Michael Hartl’s Rails Tutorial (http://www.railstutorial.org/) and watched Ryan Bates’s RailsCasts (http://railscasts.com/) to learn how to build a website from the ground up, but as someone with zero knowledge of how the web worked (e.g., HTTP requests, servers, AJAX), I got overwhelmed pretty quickly.

The thing that eventually worked the most for me was to start working on small, fun projects and Google for help (StackOverflow, coding blogs) when I got stuck. However, this type of learning doesn’t work best for everyone, so it’s important to reflect on your own learning style and find what works for you.

Fortunately, there are tons of resources and tutorials for beginners these days. Give them a whirl and read Mindset by Carol Dweck while you’re doing so to ensure you celebrate and learn from failures instead of beating yourself up about them. The most important part of the process is to keep it fun and to help yourself internalize the belief that you can do it.

MARCUS: I am a big book person. If I want to learn something, I’ll buy the book, read it, and write out the examples. I love second hand knowledge, reading tech books speeds up my growth process by introducing me to tested solutions for problem X, Y, or Z.

CHENEY: Oddly enough, I don’t have a go-to place for tutorials, but I approach it in more of an ad-hoc way. Google search is always my home base, and I try to follow relevant field leaders on social media for tips I wouldn’t know to search for. I’ve spent time on various blogs for focused tutorials (rather than full-fledged courses that I find overwhelming like Lynda’s offerings) as well as sites like bento.io.

I caution people looking to learn to avoid thinking you have to know everything before you can build anything. With so many new frameworks, trends, and options to choose from now, it’s unreasonable to think that you should have everything in your head. Instead, you should train yourself to be relentlessly resourceful. I don’t strive to be the go-to expert for Python or JS nor am I anywhere close. Rather, I strive to have the confidence that I can pick-up what I need to learn and solve any problems in front of me.

WAYNE: I can’t even remember the first web resources I used!

These days, I just use the internet at large. I often just go to people’s websites and look at the source code. To learn javascript, I went to dynamicdrive.com.

A couple years ago, I read through the source code for jQuery.

Now, I won’t sit and read an entire repo, but I’ll look at snippets here and there.

The trick is in knowing how to do a skilled Google search, and how to find the answer you’re looking for the first time.

NICOLE: Ooh, that’s a tough question – there are so many great tutorials out there. I’m a big fan of the Mozilla JavaScript Guide, and Codrops has a lot of really beautiful front-end tutorials and examples. For another comprehensive JavaScript overview, Eloquent JavaScript is pretty good, and for learning Rails, the Learn Rails By Example tutorial really impressed me with how well it balanced teaching advanced material with keeping things beginner accessible.

If you’re looking for something a bit more beginner-friendly, I highly recommend Codecademy and Khan Academy – I’ve had good results using both of these with my students.

4. What’s been the most frustrating thing about learning to code or being a developer (if you work as one professionally)?

STEPHANIE: As a developer, I’d say that there’s always a healthy tension between writing good code and shipping. You don’t want to over-engineer a solution, but you also don’t want to write horrible code that, while functional, will make it harder to iterate and improve on the feature. It’s frustrating at times because without more experience, it’s really hard to know the answer. But at the same time, it’s one of the cool non-deterministic challenges that can make programming a really creative pursuit.

MARCUS: The most frustrating thing about learning to code is learning all the associated knowledge that no one warns you about.

I started programming as a windows user. In terms of coding, everything seemed to be going fine. I had recently struggled through building a blog from scratch, and I was hoping to put it online. That was about the time where I found out that the typical server is a Linux box and, if you want to make your website live, you need to learn how to navigate Linux. I then spent the next month trying to install Ubuntu on my Windows 8 box so that I could learn Linux.

Once I had a (very) basic understanding of Linux, I tried to put my blog online again. That was about the time realized the difference between serving your code on localhost and serving your code on a Linux box that you happened to be ssh into. I also ran into a file permission issue that had me stumped for 2 months.

In the end, I did get a site running (a website that I made for my girlfriend as a gift), but the entire process scarred me for life. I just wish someone could have told me about this associated knowledge beforehand so that I could have been better prepared.

CHENEY: Imposter Syndrome. Some of the most seemingly confident people I know are developers, and these same people can also be the most insecure. In recent years, this concept is now well-written about, but it remains a common issue that it’s so easy to think that we’re just faking it.

In a way, it’s an empowering thing, because it keeps you striving to be better. On the other hand, it can be debilitating, because you’re giving time estimates you know you can’t keep and end up unbalancing other aspect of your life as you try to make up for it.

One unique aspect of writing code is the multiplier of effectiveness. Perhaps in other occupations and hobbies, an expert is someone who is only generating 3x more output than an amateur, but our industry has been enamored with the idea of a 10x engineer. With that wider range of output, it’s easy to perceive gigantic gaps between ourselves and those that we admire, and perhaps we’re a little bit too hard on ourselves on this one.

WAYNE: When you’re in a workforce, you may be blocked by non-technical issues that have nothing to do with the technology that you want to solve.

Technically speaking, there’s only one thing that I’ve found impossible: and that’s when it’s not in the API. In my role as a front-end developer, I deal with browser support issues, but that actually never bothers me. That makes me very comfortable.

The only thing that bothers me as a front-end developer is that the industry can sometimes be so back-end oriented that it’s difficult to get the respect you get.

NICOLE: One of the things that you often don’t get a great feel for while you’re still learning is dealing with other people’s code. In the real world, the APIs aren’t always going to be clean and readable, and sometimes you’ll have to support legacy code that’s messy or so old that nobody even remembers who wrote it. And of course, there’s always that other team that you’ll have critical dependencies on who can just never quite get it together. I say this a bit tongue-in-cheek, but just like being able to work with someone else’s code is a critical skill, so is being able to work with other people. Being a developer isn’t just about coding – interpersonal skills are important too – and it’s good to be able to roll with the punches, and to be able to offer constructive critique and ask for what you or your team needs without blaming or finger-pointing.

5. What advice would you give to someone just starting out?

STEPHANIE: Internalize growth mindset. Talk to yourself everyday to internalize it, if that’s what it takes. Do it wherever – on your lunch break, on your commute to work. (Nothing to be ashamed of! I did it and still do it.)

If you’re not a person who struggles to maintain a growth mindset, the most important thing you can do is to create a safe space for you to learn. That might mean avoiding events where you have to perform under pressure (e.g., newbie-unfriendly hackathons).

Spend time upfront trying to find out how you can make the process fun for you, such as by working on tiny, inconsequential scratch-your-itch projects. Try to scope projects so that you can feel yourself making progress quickly, to create a positive feedback loop, and to keep them simple so that you don’t get overwhelmed trying to learn a thousand different things at once.

MARCUS: Join a tech group, find a group of people who like to code and make them your friends, go to hackathons, listen to podcasts, watch conference videos, and read tech books. All the information and help needed to learn how to program is out there. You just need to find it.

CHENEY: Writing code is a bit different from some other disciplines. You’ll find that progress tends to be like a step function. If you find yourself in a flat part of a project, keep at it! Don’t be afraid to ask for help or look up resources.

Don’t worry about getting everything completely right when you’re learning. Set up small tangible goals for yourself. And above all else. Close some tabs. Information paralysis when you’re learning is a real problem.

WAYNE: I think everyone gets to coding and perceive it as a much harder thing as it actually is, saying “my brain doesn’t work that way.”

To me, CSS is very simple: here’re rules, and you follow them. That’s easy compared to navigating personalities as a politician or a teacher. With computers, everything is simple, so I would tell people it’s easier than you think it is.

NICOLE: Find a mentor or coding buddy, or a bunch of them! You can learn a lot nowadays from the internet, but it’s always nice to get a fresh perspective on things and get another set of eyes on your code. If you live in a city, you can probably find plenty of local meetups for new coders, and if not, there are sites like Codermatch.me (interviewer: or online learning communities like Code Buddies) to help you find a buddy.

And go to hackathons! I’ve found that’s a great place to try out a new tech stack and get introduced to lots of new ideas (and people); I know a lot of beginners can be a bit wary of going to their first hackathon, but they tend to be very welcoming places – we don’t bite, I promise!

6. Why do you keep doing it?

STEPHANIE: Creating products through programming is an awesome way to reach a lot of people super quickly. It’s incredibly motivating to build a feature and have thousands or millions of users start using it and, better yet, telling you how it’s helping them achieve their goals.

MARCUS: I love learning, and I love solving problems! Also, I love the fact that I can reuse code! One of the promises that academia makes to a math major is that once you prove something, you never have to prove it again. In the world of mathematicians that might be true, but in the world of college students, that is a lie! Programming, on the other hand, has kept that promise. The ability to reuse code is something that I cherish!

CHENEY: I love to learn and I love to make things happen. The tools don’t actually matter to me, but engineering + design has been amazing at helping me communicate the ideas I have in my head.

WAYNE: I keep it doing it for the same reason I started: to be honest, it pays a lot.

Coming out of high school, I used to draw, and I was good at math. Computing jobs were lucrative, so I thought I’d do that. As Kanye West said, you can’t have the same job for 10 years.

Being a developer is a really cushy job. You’re pretty much in control of what you can do. People don’t have a view into your code, so you hold a piece of knowledge someone else doesn’t have. Like a plumber.

(When I was at The Ladders, I built an open-source javascript framework. BloombergView.com now uses it. It’s something I’ve been building for three years, and hopefully will be out this month or the next.)

NICOLE: Because I love it! I love making things and then being able to actually use and play with what I’ve made. And as a creator of educational software, knowing that kids all over the country are learning from software I worked on is incredibly fulfilling.

Click here to read Part I of this interview series.

Learning to code, but feeling lost? I interviewed some experts, and here’s what I found. (PART I)

Read Part II of this interview series.

Almost every night in the past two weeks, I’ve gone out and talked to beginners about their experiences learning to code.

I heard many stories of struggle: the pharmacy student who’d excitedly signed up for the HTML/CSS track at Codecademy last summer, but then had gotten stuck and quit. The financial analyst who had some entrepreneurial ideas, but then tried and failed to figure out how to turn her idea into reality. The graduating business student anxious about picking up marketable skills for the job market next year. The business director who wanted to be able to understand the language of some of his co-workers better. The PHD candidate in biology interested in learning how to analyze big data with python.

I began to wonder: what were the stories of people who were able to successfully learn how to code? What frustrations did they face when they were just starting out, and how did they get past them? What advice would they give to beginners?

My goal was to interview people with a wide range of experience levels. But when I reached out to my network of friends and acquaintances, I was surprised by the diversity of responses I got back.

I am incredibly grateful to Lenny, Darrell, Henry, Betsy, and Felicia for sharing their stories with me.

About the interviewer:

Linda Peng  (@lpnotes) works at actionkit.com, blogs at this blog, plays violin when she’s not geeking out about web development, and has started spending her weekends experimenting with codebuddies.org to help people learning from code tutorials get un-stuck faster via virtual study groups.

Interviewee Profiles

Lenny Bogdonoff is a developer at The New Yorker and currently working on the New Public Arts Foundation. You can follow him @rememberlenny.

Henry Qin is a PHD candidate in Computer Science at Stanford University working on RAMCloud, a distributed, low-latency key-value store.

Betsy Cannon is a product engineer at Tumblr, Hacker School alumna, and collector of forks. She posts about math and forks at forklady42.tumblr.com.

Felicia O’Garro is a developer evangelist at NineFold and co-founder of Code Crew, a meetup in NYC for people learning to code. You can follow her @feliciaogarro.

Darrell Simmons is a freelance front-end developer currently working on 30Websites.com – a project that helps people learn to code. He writes at hellodrell.tumblr.com and tweets @drell424

1. When did you first start learning to code, and what technologies are you most familiar with?

LENNY: “I learned everywhere on the Internet. I got my first exposure to learn to program when I was in elementary school. My parents sent me to a computer summer camp. Basically it was a group of anti social geeks and a group of uber geeks. The uber geeks were instructed to teach the underlings how to walk through a week-long programming course. During the camps, I think I played more Starcraft than anything else. I went to that camp for three years. During one point I learned how to make a website on Dreamweaver.

I didn’t remember anything. The takeaway I had was stupid computer security stuff I learned. I learned how to install Trojan horses and access unprotected network settings on other people’s computers. This wasn’t so much programming as figuring out how stuff worked.

In high school I made a website associated with web comics. I liked Worms 2, the game, and started blogging on my own site. I remember being impressed by my Table layout skills and Sprite making abilities. The site I made back then Is still embarrassingly on angelfire. Link from 2004: http://www.angelfire.com/oz/tomato/HOME.html

Oddly enough, I didn’t touch programming during high school. I went through a rebellious phase and defined that I was computer literate. I decided to pursue art and design oriented subjects. Looking back, this was a great idea. I came back around to the programming by the end of college. I was working a series of hourly paid jobs and decided there must be some better way. I got familiar with WordPress, learned the rules of front end development, familiarized myself with HTML/CSS, and began from there.”

BETSY: “I first started learning to code in 2007 when my high school required me to take a Java class. I love data science (analysis and machine learning) but am also comfortable with back-end development.”

DARRELL: “Prior to actually learning to code, I started making websites with WordPress (2010). I would use pre-made themes and then spend hours trying to get the site to look how I wanted it to but usually I just ended up frustrated. I decided I needed a more fundamental understanding of what was going on under the hood. I started with Codecademy and then watched a lot of video tutorials on Lynda.com. But something just wasn’t clicking. I couldn’t conceptualize how everything actually worked together. Less than a year ago (Fall 2013), I decided to take the plunge and signed up for the Front End Web Development (FEWD) course at General Assembly and haven’t looked back. Following FEWD, I also took their Back End Web Development course. However, I still feel most comfortable on the front end.

Currently, I am most proficient with front end technologies – HTML, CSS, Javascript and most of the frameworks, plugins, and libraries that come with it. I would say I have an intermediate level understanding of Ruby on Rails and can hack together Rails apps.”

HENRY: “I technically first started learning to code in Visual Basic when I was in middle school, but I did not really grok programming until I took my first CS class at Duke, where we learned to write simple 2D games using the Fang library.”

FELICIA: “I started learning how to code while working a full-time unrelated job to web development in late December of 2012. After being laid off in March of 2013 I began to really take things seriously and even threw myself completely in the fire by taking on paid and unpaid freelance gigs for early-stage startups. I’ve dabbled with a lot of different technologies and would say I’m most familiar with HTML, CSS, JavaScript, Ruby and Rails.”

2. What was a turning point/lightbulb moment for you when you first started learning?

LENNY: “The turning point was when I realized people would pay me to learn. I could incentivize myself by getting people to pay me to work on their projects. I went on Craigslist and looked for people who wanted a website. I reached out to a few people and found someone who would pay me to make their website.

I told them I had no idea what I was doing and they could pay me less than they would a professional. The result was the ability to incentivize myself to learn. It worked really well. I have repeated this formula throughout my career.”

BETSY: “Recursion was one of the first times that I realized the power of code. Before that I would use loops and logic to brute force whatever I was working on. Recursion made me realize how much just one of two lines of code could contain.”

DARRELL: “The turning point for me was when I realized professional developers don’t actually know everything. They simply know how to find out what they don’t know. Learn the fundamentals, then learn how to break a problem down into its parts. Once you have a general idea of what you’re trying to accomplish with each step, chances are someone on Stackoverflow has already asked a similar question.

Also, javascript. The first two lectures on javascript in my Front-End Web Development class at General Assembly were mind-blowing. Javascript opens up huge possibilities that I didn’t even know where possible on the front end. With all the API’s out there, it is becoming less and less necessary to be a full stack developer. There is so much functionality you can achieve using only javascript and API’s. There’s even a JSON API plugin for WordPress so you can implement a completely custom front end on your WordPress site without writing a single line of PHP. That’s pretty cool.”

HENRY: “The closest thing for me is probably realizing that I could step through code one line at a time, or even one machine instruction at a time using a debugger. That is because reading code and understanding it has always been harder than writing the code to implement an idea.”

FELICIA: “My lightbulb moment was when I first started prematurely interviewing for full-time developer/engineer positions in May of 2013. During this period I learned that there was so much more for me to learn to become a proficient professional web developer including but not limited to the connection between the client and server side, more about object oriented programming, version control, testing and how to use client-side frameworks.”

3. What tutorials did you use when you were learning X, Y, or Z?

LENNY: “I started understanding the web through WordPress. It was a lot of trial and error. I didn’t really know where I could learn the foundation, so I took what I could get. I did tutorials, read smashing magazine articles, read through the documentation, and skipped a lot of stuff that didn’t make sense.

The best way I learned WordPress was through the example of other peoples work. I would use the same wordpress theme from WooThemes as my base and then I would expand from there. I got to the point where I would need to modify something and get stuck. That’s when I would go back to googling.

I remember being really stuck on how the wp_query function and the wp_walker class worked. I thought the code was pretty difficult and never really understood it. I would make alterations to the working code and stop when I got the preferred result.

I eventually started listening to all the podcasts I could find. Chris Coyier became an asset: I loved the ShopTalk show. Another thing that helped a lot was the history of the web. The more I understood the history of where web browsers used to be, the better I would understand why tuning where the way they were.

I decided to learn JavaScript and Ruby about a year ago. I pushed hard by doing tutorials and looking for opportunities to implement what I learned. I attended a LOT of Hackathons and meetups. I also started attending conferences. That helped me meet people who were professionally doing the things I wanted to do. By meeting people, I was able to get a holistic look at what I still needed to learn.

One thing that always stuck with me was something I read about successful programmers. The idea was that good programmers didn’t know the syntax any better, but instead were more likely to reuse code they wrote in the past. From this I started focusing my effort on learning frameworks.

When I moved away from rote memorization and started manipulating existing frameworks, I learned the most.”

BETSY: “After I had been programming for a few years, I decided I wanted to learn a functional language. I used Learn You Some Erlang for Great Good, which was a great resource, though I also recommend getting out of the tutorials and playing around the language some on your own pretty quickly and then going back to work through the exercises once you get the feel of the basics.”

DARRELL: “Codecademy started it all. I then moved on to Lynda.com for more in-depth topics. General Assembly’s Dash is pretty cool too. These all helped with the basics. However, I feel learning this way you miss out on a lot of the fundamentals. For a more fundamental understanding I would recommend an in-person class or, believe it or not, real books. There are lots of great programming books out there.”

HENRY: “The book that really helped me understand Objects and Object-Oriented programming was Head First Java. Topcoder exercises helped a great deal in understanding how to turn algorithms into running code.”

FELICIA: “I like reading books and watching tutorials afterwards to reinforce concepts. Some of the resources that really helped me in the beginning:

Chris Pine’s Learn to Program
Michael Hartl’s Ruby on Rails tutorial
Treehouse’s Front-End and Rails tracks
Code School’s Three for Five and jQuery tracks
Codecademy’s Ruby track”

4. What’s been the most frustrating thing about learning to code or being a developer (if you work as one professionally)?

LENNY: “As a freelancer, it’s understanding what the customer wants. As a designer, it’s coming to terms that what you make will not look the same. As a developer, it’s a middle ground between feeling like the problem is interesting enough to solve.”

BETSY: “Code only improves with review and by getting other people’s feedback, so I have to fight my perfectionist tendency to keep my code to myself until I’m absolutely happy with it and it’s exactly what I want to be. Products end up being better when you receive feedback early on and remain flexible.”

DARRELL: “When something isn’t working that should be! Spending hours reviewing your code only to find out you missed a bracket, comma or worse, spelled something wrong. Ugh, how annoying! However, that feeling when it works makes it all better!”

HENRY: “Dealing with poor APIs and poorly-documented APIs. The normal way that I learn an API is to skim the documentation to find the functionality I am trying to invoke, and then write a toy program to exercise the parts of the API I am interested in.

This helps me ensure that I understand the API. When the API’s are not well-documented, and I need to read the API’s source code to understand how it works and how to invoke it correctly, that wastes a lot of time.”

FELICIA: “I would say the most frustrating thing about learning how to code and being a developer is that nothing ever works the way you want it to. However, the good side of that is that there is never a dull moment and you learn a lot debugging.”

5. What advice would you give to someone just starting out?

LENNY: “Figure out what incentivizes you. Don’t give up. Show people what you make. Give yourself time to learn. Even if you don’t think you are learning, if you go through the motions you will absorb something. That’s a starting point.”

BETSY: “Choose a project to make something that you always wished existed, or something that you think is the most exciting problem ever. It’s easier to persevere when you have a clear goal that you’re excited about rather than the abstract learning for learning’s sake. You’ll pick up skills along the way and even more importantly, learn how to fit those skills together.”

DARRELL: “Don’t get intimidated. There is so much to learn and that alone can be overwhelming. I know it was for me, actually it still is. Learn to be process-oriented, not goal-oriented. There is no end point; there is no way you will ever learn everything that is out there to learn and that’s OK. If you know more today than you did yesterday that is all that matters. Baby steps really add up.”

HENRY: “a) Learn how to isolate bugs and create a Minimum, Complete, Verifiable Example. The ability to do this will enable you to ask proper questions on StackOverflow, which will enable you to get unblocked much more quickly when you get stuck.

b) Learn to use the command line to compile and run programs, before you decide to be permanently married to your IDE. There will come a time when you will need the command line to debug, even if you end up using an IDE for your day-to-day work. Learn to use Linux, even if you use Windows or OS X in your daily life. Unless you plan to work for a Microsoft shop for the rest of your life, you will be glad that you learned LInux.

c) There are (at least) two broad types of programming. One involves building applications and systems and the expertise is focused around designing and using API’s, as well as system architecture. The other involves writing programs to efficiently solve mathematical problems. Do not assume that being good at one means you will be good at the other.”

FELICIA: “Don’t compare yourself to others. Also, know that the learning-how-to-code journey is a life-long journey if you’re serious. A lot of people beat themselves up in the beginning, thinking ‘I’m so dumb’ and ‘I’ll never get there.’ But if you take the time to learn and focus, and think ‘If i don’t get it today I’ll get it tomorrow,’ you’ll get there. Also: ask questions, find a mentor, and don’t be afraid to get involved in the community.

I meet a lot of people who are intimidated to go to meetups like Code Crew even though we have an audience primarily for beginners. I’ve met people who don’t like to go to other meetups because they’re not as comfortable or good enough. Some people feel like you have to be at a certain level before you come out, and that’s totally not true.

Leading sessions for study groups and being an instructor/mentor has also been extremely helpful for me. When you’re stuck in a position where you actually have to teach someone something, you really need to know the topic.”

6. Why do you keep doing it?

LENNY: “I love it. I’m making things that people can use. It’s like art. But there’s a lot of practical value associated to what you can do. It’s always changing. There’s never a shortage of topics to learn. And you can infinitely create value.”

BETSY: “It’s fun! Being able to ask a question and then quickly distill an answer from hundreds of thousands of data points still blows my mind.”

DARRELL: “Every time I sit down to make something, I’m amazed with what I can accomplish. There are very few careers where you can continually amaze yourself.”

HENRY: “I carry the hope that some day, in some small way, I will create systems and tools that will make the world a more productive place.”

FELICIA: “I’ve always wanted to find a career that I enjoyed and that challenged me. I love to code, I love learning, and I feel a void when I’m not doing it. It’s a journey for me. Also, meeting folks is fun. You become a life-long learner.”

Liked this interview series? Please share by retweeting this post or upvoting on r/learnprogramming.

UPDATE #1: Over 30 retweets and 300 upvotes so far! Thanks to everyone who shared or upvoted!

Read Part II of this interview series.

How to volunteer in the NYC tech community with little to no effort (and gain a lot in the process!)

Some people think that volunteering requires a lot of effort. You apply to a program; they accept you; you train for a few hours, and then you commit to volunteering a couple of hours every week.

In my opinion, though, volunteering in a city like NYC — with its large and ever-growing tech community – doesn’t need to be so difficult. If you identify as a developer, or if you’re even just learning to code, you don’t need to look too far to engage.

Below is a list of my favorite spaces to “volunteer” with (in no order of preference) in NYC.

• Hacker Hours, Code Crew, NYC Python Meetup
• Women Who Code, Ladies Who Code, PyLadies
• Init Developer
• CodeMontage
• CoderDojo
• Tech for Good NYC
• Monthly Music Hackathon
• NYC BigApps
• WordPress NYC
• CodeBuddies

In general, my philosophy is that volunteering is about being present. You volunteer by going to a meetup and asking thoughtful questions. You volunteer by helping a stranger solve a technical problem that they were struggling with. You volunteer by exchanging advice and resource tips with the team you work with at a hackathon. You volunteer by talking to newbies about your own learning path as a developer.

Often, what you’ll come to find is that in the act of “volunteering,” you learn a lot too. New friends give you professional or technical advice. New mentors help you when it’s your turn to get stuck on a new framework you’ve been learning for your personal project. You serendipitously discover a lot of free stickers you can put on your laptop.

If you’d like to add to my list by offering a recommendation, please leave a comment below!

Using VVV to develop multiple WordPress sites locally (alternative to using MAMP Pro!)

Went to my first Wordcamp in NYC this weekend! Funny enough, one of the first people I met upon entering the conference was @karmatosed, whose Buddypress Theme Development book I had just downloaded for offline reading on my Safari Books Online mobile app. (I had *literally* been reading it on the subway just a few minutes before I met her. :D) So many accomplished WordPress developers at this conference.

Anyway, this post is about how I learned to set up multiple local instances of WordPress on my macbook air WITHOUT using MAMP Pro (go Vagrant!), thanks much to @DrewAPicture, a web engineer at 10Up and contributor to WordPress and to VVV. He helped me figure out “what’s next?” after the  setup instructions in https://github.com/Varying-Vagrant-Vagrants/VVV left me hanging.

I thought the instructions in the initial README were great for getting my first http://local.wordpress.dev site set up. But what if I wanted to set up another instance? Below are my notes.

STEPS FOR CREATING ANOTHER LOCAL WP INSTANCE:
0. Create a new folder in vagrant-local/www. For example: vagrant-local/www/name-of-your-project/

1. In your VVV/database folder, change the file name of init-custom-sample.sql to init-custom.sql.

2. Inside vagrant-local/database/init-custom.sql, create the databases. For example:

CREATE DATABASE IF NOT EXISTS `name-of-project`;
GRANT ALL PRIVILEGES ON `name-of-project`.* TO 'wp'@'localhost' IDENTIFIED BY 'wp';CREATE DATABASE IF NOT EXISTS `name-of-project2`;
GRANT ALL PRIVILEGES ON `name-or-project2`.* TO 'wp'@'localhost' IDENTIFIED BY 'wp';

4. In vagrant-local/config/nginx-config/sites/, create servers.conf. This is where you’ll configure your nginx. If you have multiple dev instances, you’ll have multiple server{ } blocks. For example:

server {
listen       80;
listen       443 ssl;
server_name  name-of-project.dev;
root         /srv/www/name-of-project;
include /etc/nginx/nginx-wp-common.conf;
}

server {
listen       80;
listen       443 ssl;
server_name  name-of-project2.dev;
root         /srv/www/name-of-project2;
include /etc/nginx/nginx-wp-common.conf;
}

5. In your terminal, make sure the vagrant IPs are added to the bottom of your ~/etc/hosts file.

$ sudo -s
$ cd ~/
$ cd ../../
$ cd etc
$ vim hosts

Make sure:

192.168.50.4 name-of-project.dev
192.168.50.4 name-of-project2.dev

… is added to the bottom of the hosts file.

Type exit to get out.

6. Run vagrant provision in your terminal so that the databases changes are registered.

7. Download wordpress in vagrant using the command line.

$ vagrant ssh
$ cd ../../
$ cd srv/www/name-of-project
$ wp core download

exit to get out of vagrant.

8. Navigate to http://name-of-project.dev in the browser to create a new wp-config.php file, and follow the steps.

Your database host should be localhost, and the user and password should be associated with what you input in step #2. In this example, the user and password are ‘wp’ and ‘wp.’

9. You should now be able to see your local wordpress installation at http://name-of-project.dev/!

10. In practice, it’s better not to use version control on the core WordPress docs. You can git init inside vagrant-local/www/name-of-your-project/wp-content/themes/your-own-wordpress-theme to use version control specifically on your theme.

Actionify the News

My original motivation for learning how to code wasn’t because developers were in high demand career-wise, or because there was a lot of support for women interested in tech.

My original motivation for learning was because I really, really wanted to create a mini social network for students working on civic engagement and social impact causes in their community, so that different student organizations working on similar non-profit-driven missions could connect and share resources and ultimately become *better* at what they were doing.

Incredibly, I signed up my first 300 users and created my first prototype of that site — a WordPress site with a Buddypress plugin — without knowing an ounce of code. I’d somehow convinced my freshman-year economics professor, Dr. Leachman, to be my advisor for a self-crafted independent study course on social networks and civic engagement, which in my mind validated the 8 hours a day I was spending working on the site. I was literally treating it like a full-time job, which was hilarious because in addition to balancing it with four other econ courses and a part-time job, I was also — again — in the unenviable position of not really knowing how to code.

What I mostly did, instead, was look at my WordPress files and guess at their functions. I’d change up CSS values, and google CSS snippets, but I didn’t know that it would’ve been incredibly helpful to master CSS *selectors*. I’d move around text, and accidentally break PHP, and then hilariously call up my hosting company to ask them to reverse my changes by loading an older version of the database.

Ultimately, I probably spent much more time than I needed working on development features with a hammer instead of a scalpel, but reflecting back, I don’t regret it, because it was so much fun — because:

A) In addition to installing an atrocious number of WordPress and Buddypress plugins, I was scheduling interviews with students, professors, and university staff, and learning about their goals and motivations, and trying to find buy-in where I could, and demo-ing my site.

B) People were truly excited about the potential for the social network to shine a light on student civic initiatives and local non-profits, and had lots of questions about why people would want to visit my site instead of Facebook, and loved the gamification features (which I installed using a Buddypress plugin). I got lots of buy-in from people who weren’t sure where this social network was going, but were interested in getting aboard the ride.

C) I wasn’t always able to figure out how to implement the suggestions people gave me, but I remember that it was thrilling — always — to make some small change and see it come live on the site.

Fast forward: I finally pick up a legit CSS and jQuery and WordPress book, and find it helpful for when I’m thinking up prototypes to A/B test at my job, where I’m having tons of fun trying to increase the rate of action-taking and sharing of meaningful progressive content.

Fast forward: I enroll in a 12-week Mon./Wed. evening front-end development course, have an incredible amount of fun learning with my fellow part-timer classmates, learn *that’s* how HTML/CSS/JS files can work together to *run in one’s localhost*, learn about how *filepaths* in HTML files work for the first time, and start taking the Chrome web console seriously as a debugger tool, and learn about how media queries are used for responsive design.

Fast forward: I pick up Bootstrap and Git (convenient because I end up using both for my job, where I’ve transitioned into doing front-end web development full-time), and discover that I *love* going to hackathons and learning from/working with/teaching other people.

Fast forward: I realize that I suck at javascript. I read Eloquent Javascript for the first time, but read it incorrectly — i.e. glancing at the solutions, skipping over the exercises, and not often fully comprehending the concepts I’m reading about: things like closure and hoisting and the unique treatment of the javascript “this.” I take a class on Javascript, which introduces me to a whole new world of thinking in terms of objects and classes, and I severely regret the fact that I had zero interest in taking an introductory Computer Science course (“I don’t want to have a career where I stare at a computer screen all day!” “I don’t want to follow in my dad’s footsteps!” “I probably won’t be very good at it!”) for the majority of my time in school.

Fast forward: I lose my initial, irrational fear of working with APIs.

Fast forward: I self-study Learn Python the Hard Way and  Introduction to Object-Oriented Programming with Python course on Udacity, which — funnily enough — helps accelerate my understanding of javascript. From going through Django tutorials as well, I suddenly realize how little I know of regular expressions and creating models/databases and — in general — full-stack, back-end web development.

I am lucky enough to have a wonderful significant other and family and friends who support me, though, and who have helped me discover that learning programming together — i.e. reading a tutorial together and pair programming through exercises and projects — can be an incredibly helpful part of the learning process.

Current time: I feel the pressure of learning ALL THE THINGS.

Current time: I feel the pressure of learning ALL THE THINGS, but what I do have to show for it?

Damn.

You know, this post was supposed to be about actionifying the news — i.e. using a website, in some way, to help people digest the terrible things happening in the news, and turn that outrage into positive action that can be tracked — step-by-step — and historically — through time. A timeline of real-time advocacy, if you will. That was my idea.

Somewhere, I think, my motivations got bogged down by the technicalities. And maybe that’s okay. I’ve found that the more I learn, the more I see different languages and technologies tying together, and the more competent I’ll be if I ever want to product manage and build out an incipient fleeting idea.

But I *am* starting to realize that maybe — just maybe — I need to take a deep breath, and not lose sight of the ultimate goal of mastering models-views-controllers or python or a particular javascript framework… the ultimate goal being, of course, the creation itself.

In this current world — where we have the option of choosing between Django vs. Rails and WordPress vs. Drupal and SASS vs. LESS and Twitter Boostrap vs. Zurb Foundation and Flask vs. Sinatra and MySQL vs. Postgres vs. MongoDB and AngularJS vs. NodeJS and Jekyll vs. Tumblr vs. WordPress vs. Blogspot vs. Ghost and etc. vs. etc. — let’s not lose sight of the end users and the ultimate value added of our products.

After all, no one questions that Watsi runs on X technology stack when it raises enough money to cover the medical fees of thousands of people, or that Upworthy runs on Rails when it’s able to shine million of views on formerly unknown inspiring people and projects, or that Nicholas Kristof’s writings (no code!) on his New York Times blog raises thousands of dollars for out-of-sight causes, or that Everytown runs on Y technology stack when it raises enough donations to deliver over 2 million postcards against gun violence to policy decision makers, or that the technologies behind Avaaz, Change, and MoveOn.org for their petition tools and advocacy platforms are Q, R, and S.

What matters is the user experience, the use case, and the outcome. The technology is only a tool.

So without further ado:

Dear Self:

Don’t stress out.

With reflection,

LP

Comedy Hack Day Reportback

What do you get when you combine awkward developers with awkward comedians in a single room over a weekend?

Comedy Hack Day, of course.

Participants pitched their comedy hack ideas on Friday evening, and as per my nature, I wanted to work on *everything*, so I initially had trouble deciding on a team. I started helping out a bit with the members of what turned out to be the winning team (go Timesify!) before they switched ideas, but then I decided to commit to working with my friend @nicolethenerd on her idea:

Microsoft Clippy — FOR THE INTERNET.

The project was affectionately named Browser Companion on github, and these were my contributions:

Have you ever wanted Ryan Gosling as a constant companion while you surfed the web? No? Yes? What about a Golden Snitch that moved when you hovered over it? (My other idea was to add in a helpful Rubber Duck (TM) for programmers, but alas, we ran out of time.)

The browser companions would also appear with snarky quips which the two comedians on our team had written up if you landed on certain designated websites, and we had other characters too — including Browser Bro and Subway Rat.

I learned the basics about how to create a chrome browser extension, and learned from working with the code of a more experienced javascript developer. @nicolethenerd also did an excellent job presenting. Our comedy hack didn’t advance to the final day’s round of seven presentations on Sunday, but we got an honorable mention — which meant we were probably 8th-10th place in a round of 23 demos.

By the way, if you’re interested in participating in another Comedy Hack Day this year, they’ll be in San Francisco and LA later in 2014. Sign up to stay informed: http://www.comedyhackday.org/

And to give you an idea of what it was like (since videos from this year haven’t been uploaded yet), here’s a hilarious demo from a previous year’s presentation:

Quizzing Yourself Is The Best Way, Maybe? (More Learning-How-To-Code Revelations)

If you’ve met me at all, you might realize that I love discussing web development and exchanging tutorials/resources and tips with other people. Naturally, when I heard a woman with a computer engineering background at a javascript meetup talk about picking up jQuery via a free Kindle e-book, my ears perked up.

“Which e-book?” I said, curious.

She told me to scroll down to the bottom of jQuery.com and click on one of the links there. Funny, in all time I’ve been using jQuery, I’d never paid much attention to the links at the bottom of jQuery.com — but lo and behold, there it was: jQuery Succinctly by Cody Lindley, free downloadable e-book.

Turns out this isn’t the only free e-book offered by Syncfusion, the publisher; I quickly found the full list at http://www.syncfusion.com/resources/techportal/ebooks and gleefully downloaded Javascript Succinctly (because I wanted to review prototypal inheritance) and Node.JS Succinctly onto my Kindle as well.

I should caveat that in general, I’m using other, more comprehensive resources to review Javascript objects and dip into NodeJS — but when it comes to finding ways to spend my time efficiently during a subway commute, I’ve been struggling with scroll exhaustion, wifi outages and blank screens when I try to use my iPhone’s screen to load up developer docs on the web.

Kindle presents such a nicer reading experience on the phone, and the best part was that I didn’t need wifi or spend a lot of money to read these books! Yay for productivity!

===

Okay. My second revelation during the javascript meetup occurred when I realized that the only reason I’ve found learning programming in tandem with other people rather productive was because we asked each other questions all the time. 

For example:

Person A: What is X?
Person B: I think it has something to do with Y.
Person A: Oh, really? *starts Googling*
Person A: Ah, I see, this tutorial defines X as YZ and… wait, I don’t understand this part. What does that mean when it says Y is a function of XYZ?
Person B: *starts reading too* I think it means that ZYX. Here, look at this explanation above from ABC.
Person A: That makes sense now! They’re the same thing.
Person B: Yeah, I understand it now too. Thanks for figuring it out with me.

A commenter on one of my previous blog posts mentioned “spaced repetition quizzing” from this book as a good way to make concepts stick, and I am intrigued; I am tempted to type out all my future notes in question/answer quiz format now.

Of course, writing quiz questions for review isn’t exactly a novel concept; I didn’t go through sixteen years of schooling without writing out questions for Spanish class or testing myself using flashcards.

On the other hand, I haven’t approached note-taking in programming the same way, because I’ve been learning on the job — i.e. in a non-academic setting. Maybe it’s time to start.

To be continued!

Tech Meetup Appreciation Post (With Photos!)

There is just something about listening to people talk about a programming concept in person — or having to explain a programming concept to another person — that makes mastering the material a lot more fun, and the frustrations much easier to struggle through.

Obviously the bulk of the learning comes during one’s own time — i.e. when you’re following a tutorial, or independently writing code. However, I’ve found that the simple act of going to tech meetups and talking about the web development experience with other people has been incredibly helpful in accelerating my learning. At these meetups, I’ve:

• debugged terminal/installation/language syntax problems with some slight guidance from more experienced developers;
• walked newbies through pushing and pulling from git, javascript, and Bootstrap CSS;
• solved a problem I got stuck with in the middle of doing a supplementary exercise in Tango with Django by using South, thanks to some guidance from a more experienced Django developer;
• gotten recommendations for several good Python and Django tutorials, including Two Scoops of Django, Tango with Django, and this slidedeck about epic disasters with South;
• recommended Udacity’s Intro to OOP course to a lot of beginners struggling through Learn Python the Hard Way (Hi! Hope it’s been helpful!);
• reviewed basic python and OOP concepts in random conversation;
• realized that I knew a lot more about installing Django with virtualenv than I thought I did when I had to explain it to a Django beginner;
• reviewed Python fundamentals at two PyLadies meetups and got access to some awesome slides:
• forked a Jekyll blog and collected some really useful tips about developing in Jekyll (hello, SASS and Grunt and jekyll serve –watch commands!) as well as migrating from WordPress to Jekyll

I am grateful to all those who’ve shared help, tutorial tips, and “talked shop” with me. Below is a collage of some photos from these meetups.

Andrei from a Python meetup explains OOP with drawings of houses.

I meet Marcus, who has a well-worn hard copy of this book, which you can incidentally find online for free: http://interactivepython.org/courselib/static/pythonds/index.html. This book is definitely on my reading list, by the way.

A presenter at a PyLadies meetup does a lightning talk about how his startup uses Flask and AngularJS.

I learn about how meetup.com uses multi-armed bandit to do A/B testing.

Inspiration from more experienced folks at a Google-hosted event for women in technology.

This is what the office window view looked like at dawn on a Sunday morning at a hackathon.

Sometimes astronauts are present at hackathons too.

My first time being introduced to these python notebooks — great for presentations!

Python review from a presenter.

I learn about the cool things Selenium, a Python package, can do to help QA testers. In this demo, Christie (the presenter) demo-ed the browser automagically logging into WordPress and creating a post.

I accidentally took this photo on my iPhone… this was some subway light reading from another free e-book called Think Python.

Useful screenshot from a Udacity course.

Women Who Code (a mix of complete beginners and experienced javascript devs) working on javascript!

Forking Barry Clark’s jekyll starter repo.

Re-reading Eloquent Javascript

I am re-reading Eloquent Javascript with Arthur at the moment, and realizing how much of a mistake I made reading it the first time around — that is, I read it by myself, barely typed out any of the exercises before looking at the solutions, and skimmed past sections when it got confusing.

(Although you can purchase this book online, it’s free to read online.)

Arthur isn’t a programmer in the career sense, but he double majored in math along with italian, and apparently having had practice solving mathematical problems helps a lot.

Having a study partner also helps a lot. As we read, we’ll paraphrase the content out loud, quiz each other about what we just read, google an answer when the answer to a question isn’t immediately apparent, work on the exercises individually, share our respective solutions to the exercises using JSFiddle, and puzzle out root causes when something we coded renders something surprising.

For example:

split and join are not precisely each other’s inverse. string.split(x).join(x) always produces the original value, but array.join(x).split(x) does not. Can you give an example of an array where .join(” “).split(” “) produces a different value? – Exercise 4.3

We each approached the solution differently:

var testo = ["This is a", "sentence Arthur wrote."];
console.log(testo.join(" "));
console.log(testo.join(" ").split(" "));

array = ["this", "is ", "a", "sentence", "Linda", "wrote", "with", "an", "extra", "space", "after", "is"];
console.log(array.join(" "));
console.log(array.join(" ").split(" "));

To solve this, we had to truly understand what the .join() and .split() methods did in javascript.

There’s good documentation on Mozilla:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/join
“The join() method joins all elements of an array into a string.”

In other words, you start with an array, and you turn it into a string!

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split
“The split() method splits a String object into an array of strings by separating the string into substrings.”

In other words, you split a string up into an array!

The two methods are not exact opposites of each other, though, as we just demonstrated via the book exercise.

REVIEW: Getting Started with Django Video Series on Vimeo (Kickstarter-backed), Part I

W00t, I just deployed my first Django app on Heroku! Only took about a day of debugging, but the tutorial is pretty great.

Full URL of Getting Started with Django:
http://gettingstartedwithdjango.com/en/lessons/introduction-and-launch/

By the way, I’d recommend watching the video of the tutorial and using the text below it as review or as a summary of what you’re watching. The text is not fully comprehensive with all the commands, and if you only follow the text you’ll get confused.

Created by Kenneth Love, this Kickstarter-backed Django tutorial was uploaded around January 2013. The first part purports to teach you how to create a small blogging app, and later parts feature larger demonstration projects.

Neither of the Django tutorials I’d visited so far — Coding for Entrepeneurs nor Tango with Django — had visited deployment (to Heroku, no less!) as part of the setup in the beginning, so it was a nice change. Also nice was that this tutorial:

• uses vagrant on top of Virtualbox and virtualenv, which is a best practice setup for running Django apps nowadays
• uses Postgres for the database instead of sqllite or MySQL (Tango with Django uses sqllite3, which this author recommended against in a production environment)

Note that the first chapter of this tutorial doesn’t get into creating the full blown-out microblog app yet, but does cover a lot with installation and app file setup.

The downsides? I ran into a couple of issues that took me a while to debug, and I’ll make note of them in more detail below. Also, at the time that this series was made, Django 1.4.3 was the most up-to-date version, so I made sure to install 1.4.3. and not 1.6 or 1.7 — the most up-to-date version as of May 2014.

Issues:

1) When I tried to create a new “vagrant” user in postgres, I got:

ERROR: role “vagrant” already exists

The solution was to run

1. sudo su postgres
2. dropuser vagrant

But then I had to make sure to type exit to exit out of postgres@precise64:/vagrant/projects/microblog$ and get back to (blog-venv)vagrant@precise64:/vagrant/projects/microblog$  to continue with the rest of the tutorial.

2) When I ran ‘heroku run python manage.py syncdb’, I got:

Error: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket “/var/run/postgresql/.s.PGSQL.5432″?

Luckily, someone on stackoverflow had had the same problem; the solution was to make sure my settings/local.py file was in .gitignore; otherwise, Heroku would be confused by the presence of two DATABASES = { } dictionaries in both base.py and settings.py.

3) Running multiple Django apps in my local environment created PORT conflicts

Since I had been in the middle of working on another Django app from the Tango with Django book when I started following this tutorial, I got a conflict in Vagrant with the port numbers. I ended up having to go into Vagrantfile to change one of the ports from 8888 to 8889.

Instead of being able to see my project in my local browser by just typing $ python manage.py runserver, I had to type $ python manage.py runserver 0.0.0.0:8000 to see my project in http://127.0.0.1:8889/.

Meanwhile, to see my Tango with Django project, I had to run make sure to specify a local port too: $ python manage.py runserver 0.0.0.0:8887 and http://127.0.0.1:8887/rango.

NOTE: to start working on the project again, follow these steps after getting back into the gswd-vagrant folder:
$ vagrant suspend
$ vagrant up #start the vagrant up again
$ vagrant ssh #password is vagrant
$ source ~/blog-venv/bin/activate

NOTE: if there is a vagrant conflict, make sure to vagrant halt on the other instance of vagrant running.

LEARNING TO CODE TIP: Find a Study Partner

Find a study partner.

Your partner should be a friend or significant other, not a competitor.

Read through an entire book or tutorial together. Work through the parts you each get stuck on — the parts that would’ve discouraged you or driven you to distraction had you been studying the material by yourself.

Schedule an hour every day to work on the material in tandem. Don’t skip ahead; don’t let your partner skip ahead.

If you can’t meet in person, talk on skype and use Skype’s free screenshare feature in turns so that one or the other can “drive” the code.

Make sure you both type out any code passages in the book/tutorial. Complete the exercises. Ask questions about the same passages. Quiz each other on whether you can explain new concepts.

If something doesn’t make sense, find external help. Start typing out questions on stackoverflow, and realize 90% of the way through that you already knew the answer. Use each of your respective googling skills. Find someone to take a look at your question at a programming meetup if all else fails.

Talk out loud. Constantly ask each other questions. Program individually, and then review each other’s code.

Make it a habit. Do this an hour a day.

“It’s not that you’re not smart – it’s just that repetition is often what it takes.”

I am still in the middle of learning Django.

In retrospect, starting with the Official Django Tutorial was a mistake. The tutorial jumps around too much, even in the first chapter; it’s possible to follow the instructions and get your app working, but it probably serves better as a case study rather than a beginner’s tutorial.

Recently, I read Erin Parker’s story about how she learned to program in Ruby on Rails and Objective-C in pursuit of her entrepreneurial goals, and it lifted me a little from my despair that learning Django was taking far longer than I thought it would. Okay, to be fair, I was sidelined a little by my attempts to get more comfortable with Python first. But Django still seemed scary. This was her advice:

Don’t be afraid to go through programming books many, many times! I went through the Michael Hartl Ruby on Rails tutorial 3 times before it finally clicked. […] Don’t be afraid to repeat, repeat, repeat until you’re comfortable with something inside and out. It’s not that you’re not smart – it’s just that repetition is often what it takes.”

I’m happy to report that I just re-read https://docs.djangoproject.com/en/1.5/intro/tutorial01/ after finishing the exercises in http://www.tangowithdjango.com/book/chapters/setup.html and half of https://www.youtube.com/watch?v=D5VlpgEVVg4&list=PLxxA5z-8B2xk4szCgFmgonNcCboyNneMD, and the interactions between the models, views, urls.py and databases, and why syncdb is necessary makes a lot more sense! I can also see better all the ways the official tutorial jumped around, and in some ways got me to confuse the trees for the forest.

Anyway, tldr: don’t give up. Revisit. Read carefully. Re-read.

More Python/Django Revelations

Ok, I’m still due to write a proper full review of Udacity’s Intro to Object-Oriented Programming course at some point (hopefully soon), but for now, I wanted to take a moment to say: I’m so glad I made myself go through all the videos there, because a lot of the confusing things from before, from when I was trying to familiarize myself with Django for the first time, aren’t so confusing anymore.

For example, here in the Django docs about models:

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

Looking at this piece of code for the first time, I HAD NO IDEA THAT models.Model referred to the models module, whose documentation can be found at https://docs.djangoproject.com/en/dev/topics/db/models/!

models.Model simply calls the Model class from he module models. It’s a standard base class that helps us create representations of data in Django. In the example above, too, class Person inherits properties from class Models.model.

Also, a key line from the docs:
“Generally, each model maps to a single database table.”

Makes a lot of sense now. We now have a database table named Person, with two columns for storing 30-character data: one to populate first_name, and another to populate last_name.

By the way, for the record, I’m still finding Mike Hibbert’s Python/Django tutorial on YouTube really helpful. I’d written previously about his videos in the context of setting up a virtualenv with Django.

If all goes well, perhaps I’ll stick with it and see how it goes. More soon.

May 2014 To-Do List

• Finish Udacity’s Object-Oriented Programming Tutorial (Python) Finished! Review coming soon.
• Go through another Django tutorial and start building out the app for a real personal project I am going through Mike Hibbert’s Python/Django Youtube Series and the Tango with Django book.
• Build something small with Backbone.js

Upcoming Blog Entries In Draft

• Review of a really good D3.js tutorial
• Reflections of an astronaut’s remarks from the NASA hackathon
• Review of what I learned participating in the Techcrunch Disrupt 2014 hackathon  (SASS, AngularJS design, don’t pull an all-nighter, etc.)
• Review of Codeschool.com’s Chrome Browser tutorial (surprisingly good!)

RESOURCE: Querying your Django Web App Without Using SQL

In case you need to query your Django API but don’t want to write SQL, here’s a useful video showing a summary of all the commands you can use:

Also: Ahh! Why is it that I often find screencasts to have much clearer explanations than written tutorials? In retrospect, it makes a lot of sense; the *ideal* tutorial would probably be a series of animated GIFs showing steps and the results of those actions, but nobody has time to compile a bunch of GIFs and then write out explanation texts when it’s possible to hit two birds with one stone using a screencast.

The reason I’m happy with this tutorial is because 1/3 of the way through the video, it reminded me that I could use .value(‘COLUMNA’, ‘COLUMNB’) to grab the contents of the columns I needed. And I’d failed to notice how to do it when I was skimming through the official documentation on Django querysets earlier, mostly because — well,

… look a lot different than:

Yes, I know this means I could try to read better, too. Just wanted to point out the usefulness of screencasts as a teaching method, I suppose — especially for computer-based learning.

Installing Django With Virtualenv

I’ve been looking at a couple of other Django tutorials lately, and recently — thanks to David, another Django learner I talked to at a Python meetup — I started making do with two great resources:

A) Youtube Series with Mike Hibbert:

B) Tango with Django by Leif Azzopardi and David Maxwell.

The Tango with Django book initially looked great, but I was disappointed to find that it doesn’t start off showing users how to run develop their app using virtualenv. (Some brief notes about using virtualenv doesn’t come until later in the book.) Mike Hibbert’s video series, on the other hand, *starts off* walking the user through installation and virtualenv.

For the sake of my own memory and to save myself some time from having to go play/pause through all 17 minutes of the installation video again, I decided to jot down the steps to creating a new Django application using virtualenv:

1) Create a virtualenv:

$ virtualenv --no-site-packages NAME-OF-VIRTUALENV

Replace all capital letters with a name of your choosing.

2) Activate your virtualenv:

$ source NAME-OF-VIRTUALENV/bin/activate

This gets you into the virtual environment. You’ll notice that your command line now has this prefix:

(NAME-OF-VIRTUALENV)Your-MacBook-Air:$

3) Change directory into your project folder and install Django:

$ cd NAME-OF-VIRTUALENV
$ easy_install django

You can also run pip install -U django==1.5.4 instead of easy_install django if you want to install a specific version of Django instead of the latest version.

4) Start a new project:

$ django-admin.py startproject YOURPROJECTNAME

You’re creating a new project.

5) Preview your project in the browser:

$ cd YOURPROJECTNAME
$ python manage.py runserver

After you type the second command, you’ll be able to preview your app in your local browser.

6) Create a new application within your Django project (think of an application as an ice crem tub inside your Django freezer — thanks for the metaphor, Two Scoops of Django!):

$ python manage.py startapp APPNAME

Update: I found another good tutorial! The founder behind Coding for Entrepreneurs Youtube series demonstrates the creation of a Django project in virtualenv on his mac:</p>

What I learned from participating in TechCrunch Disrupt’s 2014 Hackathon

Wow, what a night. After acquiring a ticket to the Techcrunch hackathon through pure chance, I ended up entering the door at 12:30pm on Saturday, May 3rd without a strong idea for a hack or a team. Luckily, it wasn’t too hard to find a team to join after I simply started chatting with the folks who were already seated at the tables.

I ended up working with a group of strangers who didn’t have a strong idea of what they wanted to build either, so for the first half hour or so we simply looked at and chatted with the different API sponsors. We started building on the Concur API, but ultimately drew in five more (Mailjet, Sendgrid, Evernote, Pearson, Wunderground) for the dashboard. Three of us focused on the front-end/UX/AngularJS side, and two of us focused on the API/NodeJS/back-end side.

We stayed up all night.

<figcaption id="figcaption_attachment_722" class="wp-caption-text">Techcrunch Hackathon 2014. I took this photo a little past midnight.</figcaption>

Lesson Learned #1: Don’t pull an all-nighter.
The pain from pulling an all-nighter is probably ten times worse than the pain from simply waking up tired in the morning. My plan for the next 24-hour hackathon I attend, I think, would be to finish the bulk of the code by midnight, submit the project description by 1AM to qualify for a presentation spot, make everyone go home to nap, come back in the morning, and start again refreshed.

I could feel my body start to shut down around 4am/5am. It was not fun.

#2: I really enjoy working with other developers in person.
That feeling when you commit something you think is adequate but not great, and then your teammate comes back with a spectacular design or code improvement? Pretty awesome — since in my experience, that’s when my best learning takes place.

Working in person, I also enjoyed the advantage of being able to walk over to say “Hey, how did you achieve that effect?” or to show someone my screen and get immediate feedback on what I was working on. I’ve been working in a virtual office long enough to know that it is possible to work effectively in a distributed environment, but being at this hackathon reminded me of the convenience of being able to explain something going on with my development environment without needing to type multiple words or use an app.

#3: I need to learn Backbone.js and Node.js. Preferably both.
I felt a little crippled because I could mostly only contribute to the UI, which doesn’t do much for making the web app work. So… onwards! After Django.

#4: I really like SASS!
I’d used LESS before, but didn’t care for it much. Turns out that SASS is very similar, and one of the differences is the use of $ signs instead of @ signs for variables. Working with Daniel, another front-end developer who seemed to know his way around SASS, I looked at the beauty of his CSS files, read through the introductory documentation, wrote some nested CSS myself, and promptly fell in love.

#5: Apparently $2 bills are real…?   
One of the companies/sponsors started passing out newly minted $2 bills. There were homeless people down the street. No further comment.

#6: Web development is a craft.
To be a superb full-stack developer who can also design, you need to be artistically inclined, logical, mathematically inclined, have patience, be able to communicate effectively with others, and also be able to pay superb attention to detail.

You don’t need to be a genius, but you do need perseverance and experience. Actually, experience is probably the key; I’ve met highly proficient web developers who didn’t graduate from college, and who didn’t study computer science. Nobody cares about your “academic background” as long as you can build and ship it.

Modern-age blacksmiths, anyone? No hammer needed; just the ability to type and a high tolerance level for frustration.

#7: ‘Pass-by-reference’ and ‘pass-by-value’ in javascript. 

primitives are pass-by-value.
Primitives include undefined, null, boolean, string, number, object {bar: “something”} and are pass-by-value. Values are not connected.
Special objects include function, array, regexp
Objects are pass-by-reference.
— Haphazard notes from very late night in the late, when I thought it would be a good idea to refresh my understanding of object-oriented javascript by watching http://www.objectplayground.com.

(Hah! Who says you can’t learn at hackathons?)

#8: Where to get free high-quality photos and font icons. 
I learned about unsplash.com and fontawesome.io from my team. Thanks, team!

#9: Life realizations. 
… Just kidding.
No, actually, participating in this hackathon did remind me that I was here to learn, and also made me more determined to use my skills to start building out more civic tech/social innovation-type ideas. Convenience apps that solve first-world problems are only so important so long as the Antarctic ice sheet isn’t falling apart.

#10: Sunshine is awesome.

I went home in the morning, collapsed for four hours, and then woke up barely coherent enough to decide to go for a run before the sun set.

I think I can understand why people choose to hang outside with friends and family over the weekend instead of hanging out at hackathons, but why choose the easy path?

EPILOGUE:
My team won first place for one of the sponsor prizes! Many thanks to Mailjet for the recognition, and to my hackathon teammates who taught me so much in 18 hours: Miguel, Sandra, Anthony, and Daniel.

10 Reasons I Encourage Friends To Go To Hackathons

I went to my first hackathon in November 2012, registered as a “designer” instead of a “developer,” found myself the only woman on a team, and proceeded to have the most fun, nerve-wracking, up-and-down weekend ever with a group of strangers.

This is what I remember: joy, laughter, sharing of backgrounds, learning how to work together, an argument between two team members over a code design technicality, panic, stepping in at the last hour to help finish a presentation.

Later on, one of those strangers — a marine-turned-business-consultant — would tell us that not since his military days had he had such an intense bonding experience with a team.

I wasn’t on a winning hackathon team until about a year later, at my 6th or 7th one. What I’d realized by then was that I didn’t have to win to have a great experience. Every time, it was the people I connected with that made the experience the most satisfying.

A few reasons I’d encourage any budding developer to go to a hackathon:

1. You’ll learn what you don’t know.
   • Hackathons are as much a social event as a coding event. In the process of talking to people, you’ll learn from the tools they use or the tools and resources they talk about using.
2. You’ll realize what you *do* know, and teach others about what you know.
   • Technology is big, and there’s a wide range of people who go to hackathons. An iOS developer is not going to have the same range of expertise as an Android developer or a web applications developer or an arduino hacker or a UX designer. Don’t be shy about sharing your skills — even if it’s a cool trick in Photoshop. I guarantee there will be people who don’t know how to use Photoshop too.
3. You’ll get to pair-program.
   • THIS. Pair-programming is awesome if want to focus on getting as much done as possible in a short amount of time, and would enjoy talking out problems with a partner. It’s best to find someone of a similar skill level, and take turns “driving” (typing) and advising.
4. Free food!
   • To be honest, the food quality depends on how much attention the organizers pay to it. But yes — most times, expect nourishment.
5. You’ll build something by the end of the weekend.
   • More often than not, it’s not *completely* done… but most likely you’ll have something visual to demo, and that’s all that matters.
6. You’ll automatically contribute to open source.
   • Hint: if it’s software, push it to github.
7. You’ll meet many interesting, motivated people.
   • Who goes to hackathons, if not motivated people who think it’ll be fun to spend a weekend building something?
8. You’ll make new friends.
   • Hackathons are time-sensitive, sometimes intense experiences that force people to work together. This makes for great bonding experiences.
9. You’ll be on a prize-winning team 10-25% of the time.
   • Companies sometimes sponsor hackathons to advertise their APIs or products to developers. They also occasionally sponsor prizes. What this often means is that there’s no single hackathon “winner,” but rather multiple winners.
10. You’ll grow as a developer.
    • You’ll learn a lot from talking to people, from being forced to understand better the unfamiliar framework your team picked to use, and from being able to sit by your team and ask or answer any immediate quesetion.

A few misconceptions about hackathons:

1. You have to be on time.
2. You have to pull an all-nighter and/or sleep overnight.
3. You have to be a good programmer.

You don’t have to be a good programmer, stay overnight, or even be on time to go to a hackathon. Half the time, most of the attendees won’t know what they’re working on until a couple hours in — *after* they’ve formed teams with other strangers. Approach hackathons with the willingness to meet people and to learn, and you’ll have a fantastic experience.

REVIEW: Coding for Entrepreneurs Video Series Tutorial (Build a Django App)

This tutorial took a couple of hours on Saturday afternoon and a couple of hours at Hacker Hours today, + 2 hours this evening to finish. All 21 videos were free, and you can start watching it here:

My review: videos 1-16 were great, especially since the main part I was clueless about was working with models/views/controllers — so it was helpful seeing a couple of examples laid out step-by-step. I ran into trouble twice — once because I made a typo, and a second time because I missed that a tuple containing a single value still needed a comma (seriously).

Although this (Kickstarter-backed!) series purports to be aimed at entrepreneurs with “no background,” I’m not sure I’d recommend it to a complete beginner. Yes, it does a nice job summarizing simple command line and keyboard tricks as an acknowledgment to those who’ve never encountered the terminal, but I imagine some knowledge of python (so one can roughly understand what they’re typing) and html/css would significantly improve the experience.

I was not a fan of 17, 18, and 19, since for some reason the series decided to advertise paid hosting on webfaction.com and advocated manually dragging/dropping files via SFTP.

There was also no mention of version control, or the fact that herokuapp technically allows free django app deployments from git… which would’ve been a great step to see.

20 was mostly about a simple copy/paste job of facebook/twitter plugin snippets. The series also relied heavily on bootstrap 3 to make its UI shiny, which I thought was a smart move, but I still can’t imagine anyone without at least *some* prior html/css knowledge going through this tutorial without a lot of questions.

Summary: This ended being a pretty-good-start-to-but-not-entirely-comprehensive Django tutorial. I’m going to hit a textbook next.

Udacity’s Intro to Object-Oriented Programming Class

Udacity just launched an intro to object-oriented programming class using python (as always), and I am super excited! I’d already gone through some of its Intro to Computer Science and Web Development curriculum. What I really like about the videos is that they stop occasionally to quiz you. In addition, they give you exercises and homework assignments to submit, and forums to go to if you have a question.

I’ll have a more complete review about this series after I complete more than just the first few chapters.

UPDATE: I finished! Took me about a week and a half to go through. I’ll have a more thorough review of the course up later.

REVIEW: Zed Shaw’s ‘Learn Python The Hard Way’ (Chapters 1-43)

Learning Python was a lot easier after being familiar with Javascript.

I was warned about Python’s spacing and indentation issues, which I took in stride. I also really enjoyed the lack of extra () and {}. Also, coming from javascript, I felt that the language was pretty intuitive. For loops and while loops were similar. There was even an equivalent between the console.log() in javascript and print in Python; I remember asking, several months ago, the difference between console.log and return in javascript, and I can only now belatedly appreciate just how elementary that question was.

For beginners completely new to web development, I’d still recommend learning html/css/javascript first, along with a simple introduction to github, just so they can get over the hurdles of understanding functions for the first time, why they need to use the terminal, and how file paths work, etc.

Anyway. I should probably preface that before I started Learn Python The Hard Way (LPTHW) this time, I went through about 43% of Codecademy’s Python track. It was helpful insofar as getting me used to Python syntax (its unique way of writing functions!) and some simple exercises, but LPTHW is definitely the meatier of the two tutorials. Here’s my brief review of the first 43 chapters:

Chapters 1-10

Breezed though these chapters, mainly because there are only so many differences between javascript and python re: comments, variables, and strings. I think I’d previously written about beginners possibly getting tripped up by having to use the terminal. The other thing that must’ve tripped up true programming beginners would probably be typos, but I didn’t have as much a problem with that. The thing I did have to re-familiarize myself with was the concept of substitution:

my_eyes = 'brown'
my_hair = 'black'
print "He's got %s eyes and %s hair." % (my_eyes, my_hair)

Chapters 11-20

Some notes for review:

• Put a comma at the end of each print line so that print doesn’t end with a newline character and go to the next line (Chapter 11)
• variable = raw_input(“> “)  (Chapter 11)
• txt = open(filename) creates a variable named ‘txt’ and opens up the file. print txt.read() opens up the file and spews out the contents of the file. Commenting each line of code helped me understand it a lot better. (Chapter 15)
• from sys import argv, typically seen at the top of a file, means that sys is a package, and the argv feature is retrieved from that package. (Chapter 15)
• Googled why I had to do output.close(): https://mail.python.org/pipermail/tutor/2012-January/088031.html (Chapter 17)

Chapters 21-3

• int(raw_input()) vs. float(raw_input())
• control-d exits you out of the python shell
• If you have a file named example.py, you can type python to get into the python shell, type from example import * to import all the features from the example.py package, type help(example) to see the contents of that file, and run commands against that file.
• Make sure to change a piece of string into a list using .split(‘ ‘) first if you want to use something like .pop(0) to break off the first word in the list.

• def break_words(stuff):
  """This function will break up words for us."""
  words = stuff.split(' ')
  return words

• Exercise 26: more practice with functions.
• Exercise 27:

  TRUE or FALSE -> if has true in it, true.
  TRUE AND FALSE -> if has false in it, false.

• Exercise 30: Story with a bear.

Chapters 31-43

• Start with an empty list
  elements = []
  , then use the range function to count from 0 to 5</p>

  for i in range(0,6):
       print "Adding %d to the list." % i
       #append is a function that lists understand
       elements.append(i)

• There a bunch of methods you can use on lists, like list.append(), list.extend(), list.pop(), list.sort(), list.reverse(), etc.: https://docs.python.org/2/tutorial/datastructures.html
• My solution for printing out a 2D list like [[1,2,3][4,5,6]]:

  #starting with an empty list
  elements = []
  #then use the range function to do 0 to 5 counts
  for i in range(0,2):
       new = []
       #append is a function that lists understand
       for j in range(1,4):
           if i == 1:
              new.append(j+3)
           else:
              new.append(j)
       elements.append(new)
  # now we can print them out too
  print elements

• Use while loops sparingly in python. Usually a for loop is better.
• Review your while statements and make sure that the thing you are testing will become False at some point.
• When in doubt, print out your test variable at the top and bottom of the while-loop to see what it’s doing.
• Think of using print like using your console.log() in javascript.
• Every if statement must also have an else.
• Using try/except:

  def start():
      print "You are in a dark room."
      print "There is a door to your right and left."
      print "Which one do you take?"
  
      next = raw_input("> ")
      #print (how_much)
  
      if next == "left":
          bear_room()
      elif next == "right":
          cthulhu_room()
      else:
          try:
              how_much = int(next)
              print "yay number!"
          except ValueError:
              print "Not a number or left or right. You stumble around the room until you starve."
  start()

• Q: What’s the relationship between dir(something) and the “class” of something?
  A: dir(something) gives you all the attributes of the object. The class is like the blueprint for the house.
• You can only use numbers to retrieve items from a list. You can use any type to retrieve items from a dictionary. For example: list[1] versus dictionary[‘word’].

• for a, b in states.items():
      print "%s is abbreviated %s" % (a, b)

• In Exercise 40 we finally start talking about classes!
  

  “Here’s why classes are used instead of modules: You can take the above class and use it to craft many of them, millions at a time if you want, and they won’t interfere with each other. With modules, when you import there is only one for the entire program unless you do some monster hacks.”

• When you instantiate a class, you get an object. Example:

  thing = MyStuff()
  thing.apple()
  print thing.tangerine

• Exercise 41 is pretty fun: you run a script that helps you memorize how to read each of the components in a module. For example, in English, class apple(object): def sky(self, horse) translates to “class apple has-a function named sky that takes self and horse parameters.”

One day I’m going to look back on these notes and think: “Did I really have to take notes on that?” But in the meantime…

Update: This already happened for some bullet points, hah!

The Growth Stages of Reacting to Error Messages, Web-Developer Style

Stage 1 (beginner level): Panic and call your hosting company.

Because you’re a beginner. And for some reason, English in technical jargon just Does Not Compute. To you, “Error on line 41 in askdjf2fj-sldfkjsfaf.php” means “OMG I JUST BROKE THE SITE HOW DO I REVERSE IT.”

Stage 2 (after a few months): Google.

After a few months, you start to realize that the hey, the error messages actually contain meaning, and other people have encountered similar errors! If you can’t undo what you just did to get the error, you copy/paste it into a search engine. Half the time you find nothing helpful; the other half of the time, you find something, but don’t understand enough to find the Stackoverflow solution helpful.

Stage 3 (after a few months more): You read the error like it’s English.

… And you understand enough to decipher the meaningless jargon the screen sometimes spits out from what’s really important. Then you go ahead and find the right file and fix the corresponding error. Sometimes the instructions for what to do next (like when there’s a merge conflict in git) are output directly into the console, yay!

Stage 4 (a year later): 

You know when to attempt a quick fix, when to google, when to ask for help from a co-worker, and when to say “to heck with it” and restart your server and rebuild your database. You don’t panic anymore, because you know that somehow, somewhere, at some point it will be fixed.

Okay, this is a somewhat tongue-in-cheek story of what I’ve been through with error messages. I’m learning Django now, and suddenly I’m looking forward to a lot more server-issue-related messages. I still don’t like them, but I panic a lot less now.

And I’ve stopped calling my hosting company.*

*Yes, I am embarrassed to admit this did happen when I messed up some PHP on my first ever self-hosted WordPress site. This was before I even knew CSS, okay? Okay.

OMG, I got a two-gold-star-difficulty question on Udacity right!

The question:

# Given a variable, x, that stores the
# value of any decimal number, write Python
# code that prints out the nearest whole
# number to x.
# If x is exactly half way between two
# whole numbers, round up, so
# 3.5 rounds to 4 and 2.5 rounds to 3.
# You may assume x is not negative.

# Hint: The str function can convert any number into a string.
# eg str(89) converts the number 89 to the string ’89’

# Along with the str function, this problem can be solved
# using just the information introduced in unit 1.

# x = 3.14159
# >>> 3 (not 3.0)
# x = 27.63
# >>> 28 (not 28.0)
# x = 3.5
# >>> 4 (not 4.0)

My answer:
x = 27.83
rounded = round(x)
convert_to_string = str(rounded)
before_decimal = convert_to_string.find(‘.’)
print convert_to_string[0:before_decimal]

… Okay, okay, this probably isn’t that impressive, given that I’d already gone through most of Learn Python the Hard Way before I decided to revisit Udacity, and at this point I’m comfortable enough to google and understand Python documentation when I need to.

However, I *do* remember struggling with this last year when I first went tried out Udacity. So — yay for being self-aware about how I’m improving, I guess!

One very simple python function I used that the official Udacity answer didn’t use (they just manually added 0.5 to x): https://docs.python.org/2/library/functions.html#round

Well played, AlleyNYC: Free Tech Co-Working on Sundays!

Early last year, some of my favorite casual NYC tech meetups were meeting in coffee shops and the New York Public Library on the weekends. Then, suddenly, I was getting e-mails from all three meetups about a free new venue on Sunday afternoons — at a co-working place called AlleyNYC, right under Times Square and to the west of Bryant Park.

In my opinion, it was excellent marketing for the space.

Turns out AlleyNYC also hosts weekend hackathons and other meetups that require eventbrite ticket purchases to attend, but generally on Sunday afternoons, the space is wide open for anyone to bring their laptop over to hack and chat.

A quiet late Sunday afternoon:

Perks of being on the 17th floor in midtown Manhattan: the sunlight from the setting sun continues to stream through!

When I have the opportunity to go, I’ve tended to meet a lot of cool people here, and exchanged much knowledge and tips. The audience tends to be a wide mix of beginners learning to code, startup entrepreneurs working on their apps, and seasoned developers who go to be social and to help others.

Sharing economy, indeed.

Feeling like an idiot

Last week, I helped a co-worker debug their jQuery. This weekend, I helped a stranger at a tech office hours meetup debug their R commands on a windows machine. Both times, I received incredible gratitude, and I felt proud of myself — in part for being a good google searcher of windows machine problems, and in part because I knew I’d improved my javascript skills since the very beginning.

Then there are the dark times.

Have you ever taken a class, and simply *not* grasped the problem sets easily, no matter how hard you tried? I’ve felt this way, previously, with physics and with multivariable calculus. On Exam Day you’re slightly panicking, because you know you’re going to stumble upon a couple of problems that you’ll only have enough time to solve half-way, or worse — not solve at all.

In the past, I’ve almost always emerged out of my darkest moments of self-doubt thinking “aha! Can’t believe I was an idiot and missed those two brackets!” or “aha! My eyes were just opened by the fact that you can’t apply a width to an inline element and GAH, I cannot believe I missed that” or even “aha! That… sort of makes sense, but maybe it’ll make even more sense after more practice.”

The idea that — as an aspiring engineer — my job security relies on my ability to output software (and consistently learn new ways of creating software) is sobering, but the struggle is often outweighed by the joy of the moment when something works. And like a proud writer who knows the words fit perfectly (at least until several months down the line when you realize you want to refactor), you bask in the accomplishment, and look for the next challenge. 

Yes, ours is a meritocracy, but it is also a sharing economy — and I think the “sharing” part is the key to motivating aspiring software engineers. Some of my most despairing moments have been turned around by brilliant co-workers who haven’t hesitated to share some knowledge that helped me become less confused or helped me troubleshoot an issue. It’s the kindness of co-workers and acquaintances and even strangers, I think, that really makes the open-source tech community click.

Some of us are slower at math, and some of us are quicker at math, but web development at least judges all the product outputs somewhat equally, even if one website looks better than the other (but that’s a design thing, not a programming thing.) And — assuming a similar range of intelligence — the ones who are slower at math have the opportunity to become quicker at math, too, through simple perseverance and questioning and practice.

I know I’m going to be struggling a lot more, still feel like an idiot maybe 60% of the time, and continue to self-consciously ask some smart developers a lot of hopefully non-silly questions. But hopefully I’ll also be able to look back, and start passing some of my knowledge along, and feel like an idiot only on some things.

Tech is quite a big world, after all. So many things. So much to learn.

Be a Creator, not a Consumer (also: some advice about choosing what to study in college)

As much as I love meeting and talking with tech-y people (and sometimes talking tech with unfortunate non-techie friends and family, heh), I sometimes check myself re: whether I’m spending too much time talking the talk and not walking the walk.

That is, am I just spouting off on different technologies I might’ve heard about/learned about/used quite briefly, or have I truly done a lot of work on that technology — enough to show something off?

I see parallels in other places too, regardless of industry. For example, compared to studying engineering or business or being “pre-med”, those who “major in English” have suffered their fair share of deriders who think that a humanities concentration is less valued in the job market. And yet, some of the most celebrated young people I know have been English majors (or at least non-STEM majors) — and have written strong, inspiring words — or given strong, inspiring speeches — or created passionate drawings on Youtube. I’m not sure what value each of them put on the classes they took or the degrees on their diplomas, but what I do know is that each of them would not have found the success they currently have if they had not sought to publish their thoughts and creations.

I suppose what I’m trying to say is that it doesn’t matter what you majored in in college as long as you were passionate enough about something to create something and make an impact.

I remember a job interview I had, once, during my senior year of college. What was the outcome? the interviewer asked. He might as well have been asking, How many people did you influence? How many people cared?

… Yes, I realize that in business, traffic value is influenced in some measure by Eyeball Faith — the faith that eyeball numbers can magically convert into dollars. It’s why SuperBowl ads are so expensive to purchase, companies with millions of users have sold for billions of dollars despite not being in the clear outside of VC funding, and why YouTube videos gone “viral” have launched the careers of many a pop musician/actor/director/author/figure. For better or worse, our creations are always subject to the vagaries of shareability and public traffic.

But let’s ignore traffic for now, and just consider this idea: it’s *way* more satisfying being the creator of a TV show than spending all your days only consuming your peers’ competing TV shows.

It’ll take work, but hey — that film/arts/English/tech concentration you’re so passionate about? Probably worth more than a 2.7 average GPA in a subject you’re terrible at, as long as you’ve created something to show for it at the end.

Javascript vs. Python: Simple Naming Differences

I stumbled upon this 7-minute video about objects in Javascript on YouTube:

While watching it, I realized how funny it was that similar-looking data types were called different things in different programming languages.

example = [1, 2, 3, 4]

In Javascript, this is called an array. In Python, it’s called a list.

example = {
'protagonist': 'Harry Potter',
'nemesis': 'Voldemort',
'antagonist': 'Draco Malfoy'
}

In Javascript, this is called an object. In Python, this is called a dictionary.

If you’re switching from either language for the first time, don’t get tripped up!

Learning Python the Hard Way

… and I say “the hard way” because I suddenly need to know it for work work.

I think the last time I went through Zed Shaw’s Learn Python the Hard Way I stopped around exercise 15 or 16. At that time, I had no real incentive to learn Python other than for personal interest, though. This time the need is real!

Bring it on. :-)

Neat, short (20 minute) introduction to AngularJS + Firebase

This is a pretty cool presentation demo-ing AngularJS + Firebase, an API to store and sync data in real-time. The presenter creates an asynchronous commenting web app (think: youtube comments that refresh by themselves!) using only a couple lines of javascript.

I first heard about Firebase this weekend when I saw a javascript developer get up a NodeJS real-time chat web app within a couple of hours. Glad I heard about it then; else I wouldn’t have clicked on the link in my twitter feed to this video.

Yes, Coding Can Be Fun

A friend, who once took a computer science class in college (but did not particularly like it), asked me how a hackathon over the weekend went. However, he said it in a way that suggested that it must’ve been terribly boring, as if we just stared at our computer screens all weekend. And you do this for fun?

Well.. yes, yes, I do. But I think there are a couple of misunderstandings here.

Misunderstanding #1: We Stare At Our Computer Screens All Day

Hackathons and coding-oriented tech meetups like Hacker Hours or Hack the Night Away are social events by nature, and I’ve had some of the best times talking shop with other developers, exchanging learning resources, exchanging live on-screen technical help, reflecting on the industry, and generally feeling productive in a relaxed way.

I took some social entrepreneurship classes in college, and I remember sitting around with my teammates pitching ideas and writing business plans. But at hackathons? We’re also talking to each other and pitching ideas, but then we’re working together to implement those ideas. The result isn’t a 25-page paper few people will read, but an actual prototype that took a lot teamwork and the sum of our respective design and development skills. Much more fun.

Misunderstanding #2: Web Development Is Computer Science

I admit that I’ve never taken a computer science class in an official academic setting, though I have heard horror stories from former classmates about how computer science has been either exceedingly difficult or how their problem sets have been painful to debug. CS seems like one of those subjects that one either hates or loves upon studying it for the first time.

To those who find computer science frustrating: I am happy to report that computer science is *not* web development! To be sure, knowing how to program is important in order to have any level of competence as a web developer, but there are quite a few components — such as UX design, Photoshop skills, CSS (for styling), SQL, Javascript (growing ever more popular as the main programming language of the browser) — that aren’t taught in traditional computer science courses at all.

In my opinion, web development is also more fun because I get to showcase my work in a URL to curious inquirers any day. But that’s just me.

W3 Validator is a lifesaver

W3 Validator — http://validator.w3.org/ — has been a lifesaver on a few separate occasions for me within the past year. It’s been particularly helpful when:

• I had no idea why my layout suddenly looked horrible in older versions of IE. (Hint: missing divs obfuscated by the server-side code!)
• Links — yet again in older versions of IE — suddenly stopped working. (Hint: wrapping tags around elements is actually not valid.) </li> </ul>

  … so yeah, I now make it a habit of running my code through the validator just in case I missed something. Markup issues seem so easy to fix on the surface, but the validator can help a lot when you have a *lot* of nested tags.

  Process note: The default page on the validator shows you an input box where you need to put in a URL, but you can  also validate your code via file upload or “direct input”. That is, if your markup isn’t being hosted at a public URL, you can simply view:source and copy/paste your code into the text box that appears under the “direct input” tab.

   

The Biggest Mistake You Can Make While Learning How To Code

It’s a nice a time to learn web development nowadays. The number of resources available is incredible — codecademy, udacity, coursera, codeschool, treehouse, MIT EdX.

The biggest mistake you can make is to give up soon.

When I started learning, I didn’t realize how a lot of “coding” was actually a lot of debugging. It’s a constant up-and-down struggle of solving problems. But most problems are solvable, and it just takes patience and a lot of persistence to keep going.

Some Thoughts on Human Invention

I just caught the tail end of Ground Zero Supertower, a NOVA documentary that aired on 9/11/2013, and am quite amazed by the level of money, effort, dangerous + heavy machinery, and risks that thousands poured into building the new skyscraper, memorial and museum. With the transport and mechanical costs (think: mixtures fried in 3000 fahrenheit temperatures to create heavy glass, then transported a few thousand miles away) needed to create the monuments, I’m reminded by how hardcore engineering seems so much more *difficult* than software engineering.

Human invention (including the cameras and editing techniques and software that led to the production of the well-shot documentary I watched) is amazing… yes, we are still so easily susceptible to car accidents and fires and bullets, but let’s never forget the power that people have built by taking the pieces of collective accumulated knowledge and working together**.

**Also why I love hackathons, but that’s another story.

Calling myself a front-end web developer

This time last year, I was hesitant to call myself a front-end developer. What’s changed?

• Using the terminal and using version control (github or SVN) doesn’t scare me.
• I don’t get stuck on basic jQuery errors (update: and I can help co-workers with jQuery problems!).
• I understand when to use if/else statements and for loops better.
• I know how to organize my html/css/javascript files and preview a website in my local browser.
• I use stackoverflow.
• I know how to FTP my files to a server, and how to push small projects to Heroku.
• I use the W3 validator and JSlint to validate my html and javascript.
• I use LESS and Twitter Bootstrap.
• I’ve been to six hackathons, and made friends working in tech
• I’ve realized that compared to some folks I’ve met with actual CS degrees, I’m pretty good at CSS
• I’ve had a lot of practice applying responsive design on almost all of my projects.
• I got over my confusion about how to use APIs at all, and used the Google Maps API, Tumblr API, and Flickr APIs on some projects for the first time.
• I’ve become a lot better at debugging problems, and knowing when to ask for help
• Learning new frameworks or languages has become easier because of the knowledge foundation I’ve built so far.

That said, there’s still a lot more to learn. AngularJS looks formidable. Writing complicated SQL still scares me. I’ve never had to create tables in production before. I haven’t looked into noSQL (mongoDB, etc.) much. I haven’t looked at CS50x, Harvard’s free intro to CS course. I suspect I need more practice writing modular javascript. I know just enough to apply front-end changes to a Ruby on Rails app, but I haven’t taken the leap to really understanding Rails.

To be honest, I’m pretty curious about what this entry will look next year. As long as I continue to enjoy learning web development (and blogging about it), there’s hope yet, I think.

Never going back after git

UPDATE: In March 2014, I attended an official git training by @PeterBell, hosted at Gilt! Here are my more comprehensive notes from the training: https://github.com/lpatmo/git-training-notes

Git was a bit confusing when I first started exploring it, coming from using Subversion for version control. I was used to having everything I committed go live, and the idea that everything I committed would go to some virtual staging area on my computer but not on my github account did not immediately click until… well, it clicked.

And after that, everything was fine.

(As I heard a tech conference co-attendee explain to a github beginner once, the value in not having every single thing you commit automatically be seen live by your co-workers is that it gives you room to make mistakes. You can think of a “commit” as a documented “save”/snapshot of your code. But git lets you control which commits you push to your teammates, whereas subversion does not.)

The typical commands I use when starting a new project with git:

• mkdir // Creates a directory
• git init // I type this after I cd into the directory to initialize the git directory
• [Create a repository on github.com] // All it takes is a click of a button — but this, confusingly, has to be done manually
• [Copy/paste the two commands output in the “repository created” page into my terminal] // The first set of instructions does some extra stuff that I don’t need if I already initialized the repository using git init, I believe. //

  git remote add origin https://github.com/<strong>username</strong>/<strong>repository-name</strong>.git 

  git push -u origin master

• touch index.html // This creates a file called index.html in my current directory
• pwd // Optional command that tells me where I am
• ls // This command lists the files that are in the directory. Index.html should be in here now.
• subl . // This command is configured using the sublime text editor, and opens up all the files in the directory in sublime.
• git add index.html //Adds the file so that it can be committed
• git commit index.html -m “first commit” //My first commit! If I have a couple of files ready to be committed, I can optionally type git commit . -m “first commit”. Be sure that you don’t forget the “-m” or the comment that you must type to explain the change you are documenting.
• git status //Tells me what files I’ve changed by editing and saving in the editor, and which need to be added or committed. I’ll type this often to figure out which files I’ve changed by saving in the text editor.
• git log //Tells me what my most recent commits were. Note that if I push my changes up to github.com, I’ll also be able to see my commit change logs there in a nicely visually highlighted way (green = additions; red = deletions).
• git push //Pushes up my committed files to my github.com account when I’m satisfied with my commits. I’ll do this in bursts.
• git pull // I update my local files with the commits that my teammates pushed up to the shared repository. I’ll do this before I start the day, and throughout the day.

Bug tracking ease

OH! Did I mention github’s issues/bug tracker and milestone counters? When I make a commit that resolves an issue number, I can write “resolves #87” in the commit message, and it’ll automatically close issue #87 within the repository. I found it amusing that at one point, I was using trello (a project management platform) with some hackathon friends to organize our bugs. We totally could have used github!

Yes, to be sure…

Of course, merge issues often come up, and your terminal might spit back frustrating messages such as “You do not have permission…” or “Merge conflict in FILEPATH.” I’ll discuss a few of the most common error messages I’ve encountered in another post.

But anyway… Version control FTW. I am glad I won’t be going back to drag-and-drop FTP anytime soon.

Reflections on Write-Speak-Code NYC – June 20th-22nd 2013

I landed at Write-Speak-Code just a couple of weeks after AdaCamp, and boy, it did not disappoint. The group was slightly smaller than AdaCamp’s and more training-focused. I had to miss the second day (Speak day!) to go to my brother’s high school graduation, but to make up for it, I took a lot of notes on Days One and Three.

Highlights of the conference:

• The Op-Ed Project’s training that encouraged participants to write and submit newspaper op-eds
• Pondering on what makes a person a “resource” vs. an “expert.” Wait — although many women are hesitant to call themselves experts, they may be one and the same! I particularly liked the idea about how “keeping your knowledge to yourself — no matter how “unexpert” you are — can be selfishness.”
• Learning about the different types of licenses — FreeBSD vs. MIT License vs. GNU vs. CopyLeft, etc.
• Resources for finding open-source projects: http://bit.ly/FindingOSSProjects
• Learning about SQL injection, password storage, and Cross Site Scripting (XSS) from a security expert
• Hearing from many amazing women personally about their open source contributors, technology book deals, and conference speaking activities

My full notes are on my github account: https://github.com/lpatmo/writespeakcode-linda

Using the “not” selector in jQuery

Was trying to figure out how to select every

How to write a good bug report

What you need:

• a short, self contained, correct, example</span>
• steps to reproduce</span>
• input</span>
• expected output</span>
• actual output</span>
• software and operating system versions</span>

Note: This applies to questions posted on Stackoverflow too.

Just one of the many things we discussed at the Adacamp unconference.

Front-end vs. Back-end

Are some people more naturally suited to being front-end developers versus back-end developers, or vice versa?

My understanding of front-end development (which I love) is that it’s useful to have a good understanding of the back-end technologies. I haven’t done enough back-end work to discuss whether I like it or not… but I’ve talked to a couple of people by now who’ve said that they’re die-hard back-end developers who hate doing front-end work.

Thank goodness I save all my bug solutions in e-mails

Codekit (software which web developers use for lots of cool things, but which I mainly use for compiling LESS) started acting up after a reboot of my computer recently, showing me an error starting with the following words:

Error: EACCES, permission denied ‘[FILEPATH]’…

I remember googling around and landing upon linux file permissions documentation, and eventually realizing that if I went into the root (sudo -s — a command I learned from a hackathon teammate just the week before, thanks A.!) and did chmod a+rw style.css, the compilation error was magically solved.

Now, I am about 80% certain that my fix isn’t a 100% true fix, but I am *so glad* I recorded the method I used to solve it in e-mail because… yeah, the problem just popped up again. And I went crazy for a few minutes doing git revert and trying to figure out what went wrong (I was only editing a .less file!) before I realized that the codekit error looked kind of familiar, and… hmm. Searching “EACCES” pulled up the solution I had documented in my own e-mail archives.

Moral to the story: document your bug fix methods (even if temporary), especially if the fixes are obscure.

Notes from Seattle Tech HN Meetup — Speaker: Justin Kan

Justin Kan, of justin.tv fame, stopped by the Zillow offices to give a short presentation about the many ideas he and his co-founders entertained before they landed on the “right” product — that is, something that had market value and market traction.

Justin gave a nod to the story of how three entrepreneurs from Japan turned Mieple — initially an online dating site — into Anyperk, a service that provides employees with travel, entertainment, fitness, and telecom discounts.

And then he talked about the projects that he and his team personally pivoted on — from Kieko (YC 2005), which turned into SocialCam, which turned into justin.tv, which turned into Twitch, a video platform for gamers who want to watch other gamers in play. Now he’s working on Exec, an online booking service that hires cleaners.

The summary of the presentation?

Don’t be afraid to pivot.

I should probably mention that I had no idea Justin (just like Macklemore, I found out recently!) originally hailed from Seattle until I read the introductory text on the Hacker News meetup page.

I also got the chance to meet a couple of cool people, including two freelancers, a Starbucks developer, and an Amazon developer. Half of them grew up in Seattle. Way to represent!

This meetup is just another plus that endears me to Seattle.

Photo: the presentation slides, aptly titled “Pivoting: Only for Newbs??”

Finding text in a particular file using grep

My understanding of grep is pretty elementary. I’ve recently found it useful for searching for texts contained in particular strings, though. For example:

grep "search term" *
– searches for the words “search term” in all the files in the particular directory.

More here:
http://www.cyberciti.biz/faq/howto-search-find-file-for-text-string/

Deploying to Heroku

Chapter 1.4  of railstutorial.org taught me how to deploy a Rails app onto Heroku.

But how does one deploy a static app?

After some googling, I found this from lemiffe.com.

The standard index.html file would need to be renamed into something like home.html, and the index.php file would have to include
< ? php include_once("home.html"); ? >.

And then — voila!

1. cd into the directory
2. Make sure you commit your files.
3. heroku create
4. git push heroku master

The terminal will spit back to you a URL on herokuapps.com. Finally, if you want to rename it, just use the following command:

heroku rename newname

Configuring the terminal to open Sublime Text files with the ‘subl’ command

I’d noticed a couple of people typing in “subl file/path” in their terminal to open up a file after they cd’ed into the folder, but much to my surprise, the “subl” command did not work for me. Turns out I had yet to install it!

Sounds easy, right?

I googled the instructions pretty easily (http://www.sublimetext.com/docs/2/osx_command_line.html), but predictably, like much of the things I have to install, the attempt failed — I kept getting back an error that said “bin/subl” did not exist. Googled some more, and found this stackoverflow post — which contained an answer suggesting this solution:

ln -s “/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl” /usr/local/bin/subl

Another reminder to google the errors you encounter, I suppose — especially when installing software.

Teaching a beginner Lessons 0 and 1 of Zed Shaw’s Learn Python The Hard Way

Walking J. (a complete beginner) through lessons 0 and 1 of Learn Python The Hard Way by Zed Shaw, it occurred to me that LPTHW is probably best learned as a beginner when there’s someone experienced to help you through the setup, and to answer the larger-picture questions of why you are doing what you are doing.

J. uses a PC, is fairly computer literate (he knows general keyboard shortcuts and how to create/delete files and folders), and had actually taken AP Computer Science in high school — so had some familiarity with Java. But the questions he asked me made me realize how discouraging it can be to try to run through LPTHW when you have no idea about how to set up the development environment, and why the dev environment is set up the way it is.

Some issues that we encountered:

1) Python wouldn’t download. Ha. He had Python already installed, or so he thought — but then it turned out that he had Python 3 installed of Python 2 (if you read Zed Shaw’s directions carefully, Python 2 was necessary)… and then for some reason it took a few minutes longer for his machine to recognize that Python 2 was actually installed. So we waited and waited before he was able to get a successful message upon typing “python” in the powershell.

2) The powershell looks intimidating! J. was running Windows 7, I believe — and the powershell came out with this bright blue background. For non-programmers (I remember this too from before I started using the terminal every day), it looks intimidating as heck. You don’t want to type an accidental command that’ll delete or destroy all your files.

I know, I know — this fear seems absurd to those who are familiar with the command line. I had to convince him to trust me that A) I wouldn’t make him type anything that would ruin his computer; B) that it was perfectly okay and normal to use the powershell all the time; all programmers do, especially when they’re using version control, and that typing “mkdir new-directory-name” to create a folder was BETTER than going to the start menu and creating a new folder through the user interface.

Argh. This latter point was definitely something that needed convincing on. Luckily, once he learned the “mkdir” command along with the “cd” command, I think the uses of the powershell became clearer. And then I referred him to Zed Shaw’s Command Line Crash Course . :-P

3) Understanding how the text editor works in combination with the powershell. Zed Shaw recommends Notepad++ for Windows users, which is perfectly fine, but I recommended Sublime Text to J. just for the heck of it (and maybe because Sublime is v. pretty). Anyway, from the start there was some slight confusing of Sublime Text with the Powershell — which made me realize that the clarity of Lesson 0 could have been improved with just a few screenshots. J., from his one high school CS course in the early 2000s, also expected that Sublime would act as a compiler — which didn’t happen, of course. I had to tell him to think of Sublime like a Microsoft Word document — it’s just the text editor. But you can run it in the command line with “python filename.py”, or even preview it in the browser if it’s a .html file. But by itself, there’s no built-in “compile” or “preview” tab.

Setup took longer than I’d expected, but it was worth it in the end to see the spark of delight in someone’s eyes, saving a file called ex01.py and running “python ex01.py” successfully in their powershell for the first time.

I told J. that he’d probably be able to catch up with me pretty soon; I’m only Lesson 11!

Someone once asked me…

Someone once asked me whether I had a startup bug. I don’t think so; it’s more that I have an “I have so many ideas for cool things that great design + web interactivity can do to help bring people together in a shared marketplace” bug, but I end up just spending most of the time frowning at my laptop because of a) code or installation bugs; or b) because I don’t have version control or ssh set up for my personal projects yet. Argh. But that is changing pretty soon!

Update: Version control (git) set up now. Yay.

Zed Shaw is amazing

A year ago, Zed Shaw’s “Learn Python The Hard Way” was the online resource I was hearing about from everyone. I never ended up trying it out, but I flipped back to it just now and was… gratified, I suppose, to skim through the first few chapters and realize that everything was familiar, and setting up the development environment and working with the terminal did not so seem so challenging after all.

I then stumble upon Zed’s Command Line Crash Course. And realize that he also has a SQL course which purports to “teach you the 80% of SQL you probably need to use it effectively.”

Gah, there really are too many online resources out there for learning web technology. All I can do is attempt to continue to chronicle my experiences.

A nice cheatsheet for creating graphics for social media

The infographic below is courtesy of LunaMetrics. I found it while googling for the dimensions of a typical Facebook wall photo.

The Coding Diaries: Spring 2013 Resolutions

1. Use Github (see: version control) a lot more.

2. Develop a responsive WordPress theme, step by step, with the help of some WordPress theme development guides.

3. Update my personal site.

4. Become much more comfortable with Javascript.

5. Dip a toe into Rails by working on a Ruby project.

6. Finish Udacity’s CS253 course by building a web blog using Google App Engine.

7. Play around with Tumblr/Google/Facebook APIs!

8. Read more books about interaction design.

9. Create an infographic using Photoshop.

10. Spend time with fellow learners, and attend even more tech events.

Chrome Developer Tools, where you have you been in my life?

I remember the first time someone told me that I should be using Chrome Developer tools, or Firebug, or some variation thereof in the browser to help with my front-end coding.

I didn’t get it.

Now I can’t live without it! Because, you see, view:source is only helpful to a certain extent. When I’m coding an HTML/CSS/Javascript template, and the jQuery isn’t working, for example, I’ll hit option-command-J, and it’ll show me the exact line in the javascript file where the error is occurring. Click on “Elements” within Chrome Developer Tools, and I’ll be able to see height and width dimensions for elements on the page.

Once upon a time, I remember feeling at a loss about the hex code of a background color of an element I was trying to replicate. Now, it’s simple: open Chrome Developer Tools, perhaps click on the element with the inspector tool, and look at the CSS.

Why I’m Falling More And More In Love With Sublime Text

Over the past week I’ve discovered that not only can I copy the file path of my document by right-clicking and selecting “copy file path” in <a href=”http://www.sublimetext.com/” target=”_blank”>Sublime Text</a>, the text editor also allows me to short-handedly insert a comment by typing command-/ on the mac.

In other words, instead of typing out <!–comment–> in HTML or /*Comment*/ in CSS, I’d just have to press two keys!

And instead of trying to memorize file paths when I commit files, all I’d have to do is right-click-copy!

Hurrah for small, seconds-saving victories.

Book Review: “The CSS3 Anthology” by Rachel Andrew (5 Stars)

I flipped through this book in the same way that I flipped through the HTML & CSS book I noted earlier — that is, from cover to cover.

It. Is. Amazing.

I thought the book was unique in its organization style; section titles are comprised of “How can I make this happen” questions, followed immediately by a summary of the solution, a code sample, and a discussion of the code.

For those more experienced with CSS/CSS3, just glancing at the CSS code sample is a good enough review; for those less experienced, the few paragraphs of discussion text are enlightening.

I was seriously pretty happy with this book; I felt like it answered all the questions I had when — especially in the early days — I had a lot of “How do I do this with CSS?” questions that I had to google to find the answers to.

Yes, yes, everyone learns by googling — but this book is a pretty good compilation of the common questions that anyone who hasn’t had a formal course in CSS(3) would have, and would probably save the beginner a lot of time.

First impressions of CodeSchool’s jQuery: First Flight

Codeschool is the author of <a href=”http://tryruby.org” target=”_blank”>Try Ruby</a> and <a href=”http://try.github.com” target=”_blank”>Try Git</a>. I just watched the first video in their <a href=”http://www.codeschool.com/courses/jquery-air-first-flight” target=”_blank”>jQuery: First Flight</a> series, and attempted some of the follow-up exercises.

Verdict: I’m impressed! I like the polished look, the try-it-yourself exercises, the gamified set-up (you “earn” points for answering questions correctly and “spend” points on hints), and the fact that you can <a href=”http://courseware.codeschool.com.s3.amazonaws.com/jquery_air_slides.pdf” target=”_blank”>download the slides</a> from each video for reference as you complete the exercises.

I’m not certain yet whether I’m up to paying the $25/month subscription fee for access to their other videos, though; maybe after I’ve completed their three free series, I’ll take a look at the other course offerings.

Bonus: I think they mighty’ve gotten the pianist from <a href=”http://www.mertonshow.com/about” target=”_blank”>The Merton Show</a> or something to front all of their introductory videos. The intro songs are all hilarious.

The light bulb moment for me…

… was when I finally realized that I could *preview* HTML/CSS/Javascript files in my browser by typing in some variation of…

file:///Users/myname/Desktop/folder/folder/folder/index.html

…in a chrome or firefox browser.

There was a time, scarcely less than a year ago, when I had absolutely no idea what to do when an online tutorial gave me a button to download a file package. Now, I can’t believe how straightforward the idea of HTML, CSS, and Javascript files working in sync are.

Essentially:

1) You start with the HTML file — usually named index.html or some variation thereof. You can make sure it starts with a <!doctype html> (go HTML5!), has tags where you put your and tags, has a , and possibly some

‘Sublime’ (The Text Editor) Is Pretty

So. Here’s my history with text editors:

• I started with notepad++ on a PC. It was all right; I really enjoyed the ability to “run” my code in a web browser by clicking from the menu. This was before I understood much about file paths, and how it’s possible to view .html files without going through that user interface step.
• I tried out Coda, but I didn’t really like its “preview” feature. It also cost $79, so I eventually settled on a free editor called Aptana.
• At the urging of an instructor at General Assembly, I installed Sublime. I’ll occasionally get alerts requesting me to consider purchasing a license, but I love it so far! It’s #1: pretty; and #2: works well with the command-o and drag-drop-file-into-text-editor shortcuts (unlike Aptana); and #3: can open up to 2 or 3 file columns.

Screenshot below:

Of course, two months later, I might very well be blogging about how much I love NetBeans…. *grin*

How I Converted To Mac From PC

I was a windows user for… well, ever since I started using a computer. Then I got side-saddled with a mac. Then I looked up some mac keyboard shortcuts. Then I got used to the idea of typing “command”-key rather than “control”-key and FINALLY figured out that it was easier to press the “command” button with the thumb rather than with the pinkie.

Then I started using all of these shortcuts:

1) Taking a Screenshot

• shift-command-4

3) Scrolling left, right, up, or down a page without the use of a mouse

• swipe with two fingers simultaneously on the mousepad!

… Anyway, work on the computer has never been more fun now. The mac loads instantly in 2 seconds, whereas it took more than 30 seconds for my [admittedly kind-of-old PC] to load.

Hacker News Readers, You Make Me Laugh

Here’s a brilliant spoof of a set of recent headlines upvoted to the front page of news.ycombinator.com:

Source: http://us2.campaign-archive1.com/?u=193b767bbb3b0eb0d949d5924&id=0c3a567f95&e=5603c292b3

Erm. Hi. FTP.

I can’t believe it took me this long to figure out how to connect to my Bluehost account in FileZilla.

But yes, here are the easy instructions: https://box363.bluehost.com:2083/frontend/bluehost/ftp/accounts.html

Y’know, I think the only reason I haven’t done this sooner is because I had been in the very terrible habit of editing files directly in my bluehost or WP accounts. I’d never watched someone go through all the steps of working on files saved locally /before/ committing them to the site until very recently, when I sat in on a hands-on WordPress development workshop. I learned so many small but useful things in that class! It definitely deserves its own post at some point.

Anyway, lesson learned: not everyone uses git or subversion to commit files to their sites.

Note To Self: Remember To Close Tags

… and end jQuery line breaks with semicolons (;). And don’t forget the % before the } closing bracket in Mason. And don’t forget the question mark at the beginning of a bracket in PHP (<?php).

Always saves time to pay attention to the small details when you’re setting foot in a new language. :-)

REVIEW: HTML and CSS Book by Jon Duckett

A couple of weeks ago I found a copy of The HTML and CSS book in my bookstore. It looked very visual, so I started flipping through it — and before I knew it, three and a half hours had passed and I had read/skimmed through the entire 490-page book.

I promptly bought it for a couple of reasons:

• It’s very pretty!
• I could see myself using it as a reference book. What I’d learned about HTML and CSS thus far had mostly come from googling occasional articles and reading CSS: The Missing Manual, by David Sawyer McFarland, on my ipad. My e-version is great, and goes into a lot of detail, but doesn’t quite make it as a handy reference guide.

I was happy with the fact that although much of what I was reading was already familiar, there were small details that filled the gaps of my knowledge. And the book was organized in such a way that the placement of each chapter (color-coded!) made total sense.

I lied: I actually ended up buying two copies — one for myself, and another for my boyfriend who had expressed some desire in learning web design.

</span>

Did you know you can preview your randomly saved .html and .php files on your web browser?

On mac, type in:

• file:///Users/YOUR_USERNAME/folder/wherever/you/saved/your/file.html

I also learned that typing “../” moves up a directory from the level you’re currently at. For example, if an image called “cat.jpg” was saved in a folder whose root folder was above a level from the document that you’re working in, typing in “../” moves you up to the level of the root folder. Then all you would need to do is type in the path where cat.jpg was saved. Here’s another example in practice:

• <img src=”../rootfolder/animals/cats/cat.jpg” />

</span>

Some Day I’m Going To Make A Scrolling Infographic Page Like This Too

I’ve seen scrolling infographics shared on Hacker News many times, and they never cease to make me smile. Here’s my latest discovery:

As always, I like these types of pages because they 1) have the potential to go super-viral; 2) tend to be very visual; 3) are great for breaking down simple talking points and ideas. This one is created by Atlassian. Was anyone else tempted to submit an email into the large input box at the bottom?

</span>

Things I Should Have Figured Out Earlier, But Didn’t Until People Talked To Me

Two truly helpful things I learned from conversations with other people this past week:

• I can record pretty high quality on music on my iphone using the Multitrack DAW app if I decrease the input signal. I should’ve figured this out earlier!
• In <a href=http://www.optimizely.com" target="_blank">Optimizely</a>, an web optimization and A/B testing tool, there is a way to target changes sitewide using substrings.

</span>

My Set-Up Environment For Learning From Tech Books

Step One: Read book. I’m usually on an ipad with a Kindle purchase or with the Safari Books Online app, or on a tab in the Safari browser).

Step Two: Type notes on web browser. I recently discovered an organization platform called workflowy.com, and I really like using it to organize everything in my life all the to-dos I have related to my personal projects. I find it useful for typing notes beneath bullet points, too, since the platform lets you switch in and out of document mode pretty easily.

Step Three: Use jsfiddle.net. It’s lets you fiddle with HTML, CSS, and Javascript all on the same web tab and lets you see the results of your work with a single click.

</span>

“No Thanks, You Don’t Deserve It.”

I just saw a pop-up on earbits.com that asked me to share the site on Facebook or Twitter. Instead of an X button on the top right-hand side, however, they placed a small line of gray text for me to click on that said “No thanks, you don’t deserve it.”

The mean-spirited message gave me pause. I wanted to be nice. I impulsively clicked on the twitter button. Shared!

It was a clever message.

^{The “thank you” text immediately replaced the previous message after I clicked to share.}

</span>

What I’m Learning From TutsPlus.com’s jQuery In 30 Days E-mails (Free)

I started receiving Nettuts+’s 10-minute-ish video tutorials in jQuery a couple of days ago. Ran through the first lesson last week, but didn’t get a chance to open up the next one until today. (I have a pile in my inbox, now.)

So far I like it! The videos are good refreshers for what I’ve read in textbooks so far, and they’re short and easy to understand (which is a huge plus, since they’re targeted at the absolute beginner.)

</span>

How To Magnify A Graphic In 5 Steps (The Beginner jQuery Way)

A few weeks ago I tinkered around with “zoomifying” a graphic upon mouseover. I quickly discovered that I needed to add a “mouseout” event, so with some more hobbling around I was able to write up something that works. I have the feeling that experts would have written it more simply — but hey, it works!

For this tutorial we’re going to assume that the natural width of the image is 300, and the magnified width of the image is 800px. Note that the jQuery library must be called before any of the jQuery can work.

Mouseover the image to see example:

Step 1:
Save the image in its original, high-quality size.
Step 2:
Upload the high-quality image into PicMonkey (or another photo editor) and find the heights for when the image is resized to width=300 and for when the image is resized to width=800</p>

Copy and paste the following script to the top of the WordPress post. Switch out the heights that you found from picmonkey.

Step 3:
Get rid of the tags in the image on the post. So

<pre class="syntax {CSS}> </pre>

becomes

<pre class="syntax {css}> </pre>

Step 4:
Change the class to be equal to “infographic1″, and edit out the title to whatever you desire.

<pre class="syntax {css}>> </pre>

becomes

<pre class="syntax {css}> </pre>

Step 5:
Click “preview” to check that the zoomification effect is working. Double check the other steps if it’s not.

</span>

Magic

I remember the first time someone wrote a short piece of code in front of me that output one string of text when it was a certain time of day, and another string of text when it was another time of day. I thought it was magic. How did he know what to write?

Nine months later, now that I’ve scratched the surface a little, I understand that most of it is syntax — knowing what works, what doesn’t. Every snippet has a starting bracket and an ending part; there are certain concepts (such as if/then statements) that will probably work in a couple of different derivative languages. I’m still picking up pieces here and there, but I think it’s time to get serious by opening up a few textbooks. I’m pretty happy to have access to Safari Books Online.

</span>

Small Lesson

Today I was reminded that an innocent-looking apostrophe inside a string can break the entirety of a javascript file.

That is all. : (

</span>

A 30-Minute Youtube Talk On Data And Design

Idan Gazit talked about data visualization at Pycon 2012 and gave some very interesting examples on how color, relationships, and type faces are used to present information. I was excited to listen to his 30-minute presentation:

The interesting message that I took away? Relationships matter. That is, people will always be looking for clues surrounding the information presented. The number “5”, for example, is huge when placed next to a “3”, but tiny when placed next to “1000.”

That exactly wasn’t an example Idan used, but rather my over-simplification of an idea that provoked me the most.

Anyway, many thanks to the front page of Hacker News for the link!

</span>

Lessons Learned From Beginner jQuery Fail

Reading Javascript & jQuery: The Missing Manuals was influential in several ways:

Then I attempted to do a simple .show() and .hide() (translation: hiding an element, then showing it upon a click) today with jQuery, and it didn’t work. Asked a co-worker who’s an experienced web developer, and he suggested I start using a debugger of some sort. He kindly linked me to Chrome Developer Tools, which showed me that there was a syntax error in the javascript.

What, you might ask, is a syntax error?

I did some googling, and some asking, and apparently the majority of syntax errors have to do with punctuation — such as forgetting to close a line with a semicolon, or forgetting parentheses.

I stared at the code. Stared some more. Then I finally had the bright idea to compare my code with another example of jquery that was working (I used this), and that was where I immediately saw that I was missing an entire set of closing parentheses });.

Whoops! Guess that I means I need to reread my book. Or just start practicing with some more examples.

My co-worker also pointed out the console.log(“comment about what your javascript is supposed to be doing here”) trick, which is achieved by putting that line above every piece of javascript you want to test, opening up browser tools, and then seeing if the line you typed runs in the browser console. He told me that it’s a good idea to get rid of these lines when the code goes live, though, because of compatibility issues with IE9.

Hurrah for super-helpful co-workers! Sometimes it’s good to have mentors who know their stuff. And to cross-check code with a working example rather than staring at it blindly, of course.

</span>

Photoshop! Finally.

I went to an API hackathon, and ended up watching a 19-year-old college freshman dominate Photoshop CS6 with a tablet. After that, I couldn’t help but take out my 30-day trial of CS6 too. As a long-time user of Microsoft PowerPoint, web apps like PicMonkey, and other tools where clicking on an item selected it, figuring out how to play around with layers was the biggest learning curve. But after that? Wow.

I was honestly pretty excited to finally unveil the mystery of how transparent graphics were created. Hurrah for magic eraser tools:

I also discovered that once you get through the initial curves of realizing that keyboard shortcuts are your friend and that layers are not selected by clicking on the canvas, Google really *is* your friend.

I’m sure I still have much to learn, but in any case, these basics I’ve googled have been really helpful in getting me to wield Photoshop as easily as I did Microsoft Paint:

• command-[ and command-] moves layers backward and forward, respectively (you can also manually drag them up and down) (
• command-T lets you adjust the size of a layer after you select it
• If you *do* want to select a layer that you point to right on the canvas, you have to hit command-click
• control-option adjusts the size of your circular brush tool
• It *is* possible to change the canvas size in the middle of editing! Simply go to image -> canvas size. You can also adjust the dimensions of an image by going to image -> image size.
• Press ‘b’ for the brush shortcut, ‘v’ for the view shortcut, ‘c’ to crop the entire canvas, ‘t’ to write a block of text, etc.

I’m probably going to read through a book about Photoshop soon — but for now, I’m happy to be comfortable with knowing enough to create some of my own custom graphics.

</span>

How To Get Started With CSS

Let’s try a simple example by learning how to recreate the block of text above. (Yes, that block of text hat vaguely looks like it rests on a yellow post-it-note.)

But let’s not work with so much text. Ah, here’s our new HTML:

This post-it note has been purposefully simplified to contain fewer words.

But we want to style it, right? So we’ll need to select it some way. Let’s do this by wrapping a div around it. Let’s name the div “postit.”

But should we let “postit” be an ID or a class? You can read about the difference here. For the purposes of this post, let’s make it a class so we can reuse the div.

  This post-it note has been purposefully left blank.

Awesome! Now that the body of text we want to select has been selected, all that’s left to do is to write the CSS that styles the text. The most common method is to place the CSS in an external style sheet, but for the purposes of this post, let’s just write it above the HTML (otherwise known as an internal stylesheet). Makes it easy to see what happened at a glance.

The first thing to remember, when writing CSS above the HTML, is to type these tags:

See the space in the middle? That’s where we’re going to put the CSS. Since our div is a class, we type a period before the name of the div (“postit”). (Note: if it were an ID, we would have typed “#” in place of the period) Then we type in a set of brackets, inside of which will contain the styling.

Now: what styles do we want? Say we want the font color inside the div to be a certain shade of blue, or the hex color code #369. This is what we’ll type inside:

Note: Do NOT forget the semicolon after the statement!

What else do we want to do with our block of text? Right underneath “color: #369″, type in:

width: 30em; 
display: block;

This transforms the div into a block with a width of 30em, which is the same thing as 480 pixels. (Why type in “30em” instead of “480px”, which does the same thing? Stackoverflow members answer the question here).

Let’s also add in the following:

background: #ffc;

This makes the background color a post-it color yellow.

padding: 30px; 

This introduces some distance between the border of the div block and the text inside by a measure of 30 pixels all around.

The final step? Adding some box shadow.

-moz-box-shadow: 5x 5px 7x rgba(63,33,33,1);
-webkit-box-shadow: 5px 5px 7px rgba(63,33,33,.7);
box-shadow: 5px 5px 7px rgba(63,33,33,.7);

Here’s what your final product should look like:

  This post-it note has been purposefully simplified to contain fewer words.

And you’re done! Make sure that your notepad++ file is saved as an appropriate .html or .php (which could also work), and preview it in your browser. Here’s what you should get:

</span>

Why Your CSS and Javascript Might Not Be Working In Your WordPress Post

I was working on a CSS/Javascript design that involved a couple of thumbnails the other day. Clicking on each thumbnail would generate the corresponding video or graphic, and hide all the other pieces of content. I coded the design in notepad++, tested it in a couple of browsers, and made sure it worked. Then I pasted the code into the HTML editor of a WordPress post, hit “preview,” and encountered a mess.

Thanks goodness for co-workers who code. Since I couldn’t figure out why my code was working in my text editor but not in WordPress, S. looked it over for me and figured out that WordPress was adding paragraph tags to all the blank lines in my script. Some of these tags ended up in the middle of the CSS and Javascript!

Needless to say, we deleted all the blank lines. S. also ended up simplifying my javascript. As for me, I’m back hitting the books.

</span>

Day 2: Resizing Images For The Blog

UPDATE: Picnik is closed. Picmonkey.com works similarly!</p>

Getting images the right width and height are quite important in web design. I remember learning this the hard way when I was trying to create banner text for a slider content plugin for WordPress which called for images of the same size. Lacking any background with visual graphic tools beyond Microsoft Paint, I stumbled my way through it by approximating the size of my banner using post-it-notes and my Microsoft Paint program as an editor.

Luckily, I later discovered that there’s a free tool resizing tool for those who lack a copy of Photoshop. Here’s what you need to do:

1. Go to picnik.com
2. Click on “get started.”
3. Upload a photo.
4. Click on the “resize” button to make it scroll down. Now you can reformat the image you uploaded to any size you want. The first field signifies the width, and the second field signifies the height. So 49 x 51 would be equivalent to 49 px (or pixels) wide, 51 px (or pixels) tall. In HTML, you might end up doing the same thing by typing <img src=”URL of Image” width=”49″ height=”51″>.
5. Click “apply” and “save.”</p>

</div>

There are also a few other cool effects in Picnik that let you put text on your image, change its coloring, doodle on it, etc. Have fun clicking around!

</span>

Resource: John D. Cook’s Intro. To R For Programmers

Want to learn R? This is worth a read if you know a little bit of programming. If you’re confused about where to type in the code, check out this post and watch the 10-minute introductory video.

</span>

Day 1: The Difference Between WordPress.org and WordPress.com

I remember the first time I started playing around with a free blog hosted on wordpress.com. It was great, I couldn’t believe I had a live site within minutes, and playing with different themes became kind of addictive. The trouble was, I didn’t know CSS, and I also wasn’t given the power to customize the site any more than change the placements of a couple of widgets unless I wanted to change the theme. I also noticed talk about different “plugins” that I definitely could’ve found useful, but I couldn’t install any beyond the ones that WordPress.com had approved.

You should check with your hosting provider to figure out how to install WordPress. Some services, like Bluehost, let you install it with one click (it really is that easy). WordPress is a very popular CMS (content management system), so the question should be old beans for any hosting provider you’re researching.

</span>

Source Control: How I Discovered Its Importance The Hard Way

Last night I made the mistake of editing the files for a new WordPress child theme directly in Appearance -> Editor. It was going swimmingly until I added a few lines of CSS and changed some of the HTML in header.php. When I refreshed the page, the layout of the site had broken. And I backed up a few steps, but I couldn’t figure out what was wrong.

That was when I realized I really should be coding in a development environment, and definitely not on a live site.

I’ve heard that Github is the most widely-used platform for open-sourced software development nowadays, so I’m going to put myself through some of its videos and start working with it. Here’s what I’m hoping I’ll be able to learn:

• How to track changes and easily revert to an earlier version/backstep if I do something stupid
• How to push a particular code version to a live site

For updates to this entry, check out the “github” tag.

</span>

Learning How To Code ==>> Saving The World. Sort Of. Well, It’s A Possibility.

It occurred to me, recently, how satisfying learning how to develop for the web could be. Sure, there are the frustrations when you type in a few lines of code and something that should work doesn’t, but once you spend enough time staring at the screen (or double-checking all the lines you know you were supposed to include, or dragging in a third party for help), there’s a good chance that you’ll eventually figure it out. And at that point, the feeling is magnificent.

Because it’ll be working. And if it’s been deployed to a live site, you can always send the URL to someone to show it off.

Me: Check this out!

Friend: All I see is a button, and all it does is change colors when my mouse hovers over it. I don’t even know what the button does.

Me: I know! Isn’t that so cool?

Friend: …

Successfully troubleshooting code for the web reminds me of the satisfaction I used to feel in eighth grade when I successfully applied a new concept to a slightly tricky algebra problem. But it’s even better because whereas the final answer to an algebra problem is kind of useless, the final answer to a web development problem has several possible real-world implications.

For example:

Jekyll Introduction

This Jekyll introduction will outline specifically what Jekyll is and why you would want to use it. Directly following the intro we’ll learn exactly how Jekyll does what it does.

Overview

What is Jekyll?

Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.

Examples

This website is created with Jekyll. Other Jekyll websites.

What does Jekyll Do?

Jekyll is a ruby gem you install on your local system. Once there you can call jekyll --server on a directory and provided that directory is setup in a way jekyll expects, it will do magic stuff like parse markdown/textile files, compute categories, tags, permalinks, and construct your pages from layout templates and partials.

Once parsed, Jekyll stores the result in a self-contained static _site folder. The intention here is that you can serve all contents in this folder statically from a plain static web-server.

You can think of Jekyll as a normalish dynamic blog but rather than parsing content, templates, and tags on each request, Jekyll does this once beforehand and caches the entire website in a folder for serving statically.

Jekyll is Not Blogging Software

Jekyll is a parsing engine.

Jekyll does not come with any content nor does it have any templates or design elements. This is a common source of confusion when getting started. Jekyll does not come with anything you actually use or see on your website - you have to make it.

Why Should I Care?

Jekyll is very minimalistic and very efficient. The most important thing to realize about Jekyll is that it creates a static representation of your website requiring only a static web-server. Traditional dynamic blogs like Wordpress require a database and server-side code. Heavily trafficked dynamic blogs must employ a caching layer that ultimately performs the same job Jekyll sets out to do; serve static content.

Therefore if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.

Developers like Jekyll because we can write content like we write code:

• Ability to write content in markdown or textile in your favorite text-editor.
• Ability to write and preview your content via localhost.
• No internet connection required.
• Ability to publish via git.
• Ability to host your blog on a static web-server.
• Ability to host freely on GitHub Pages.
• No database required.

How Jekyll Works

The following is a complete but concise outline of exactly how Jekyll works.

Be aware that core concepts are introduced in rapid succession without code examples. This information is not intended to specifically teach you how to do anything, rather it is intended to give you the full picture relative to what is going on in Jekyll-world.

Learning these core concepts should help you avoid common frustrations and ultimately help you better understand the code examples contained throughout Jekyll-Bootstrap.

Initial Setup

After installing jekyll you’ll need to format your website directory in a way jekyll expects. Jekyll-bootstrap conveniently provides the base directory format.

The Jekyll Application Base Format

Jekyll expects your website directory to be laid out like so:

.
|-- _config.yml
|-- _includes
|-- _layouts
|   |-- default.html
|   |-- post.html
|-- _posts
|   |-- 2011-10-25-open-source-is-good.markdown
|   |-- 2011-04-26-hello-world.markdown
|-- _site
|-- index.html
|-- assets
    |-- css
        |-- style.css
    |-- javascripts

• _config.yml Stores configuration data.

• _includes This folder is for partial views.

• _layouts This folder is for the main templates your content will be inserted into. You can have different layouts for different pages or page sections.

• _posts This folder contains your dynamic content/posts. the naming format is required to be @YEAR-MONTH-DATE-title.MARKUP@.

• _site This is where the generated site will be placed once Jekyll is done transforming it.

• assets This folder is not part of the standard jekyll structure. The assets folder represents any generic folder you happen to create in your root directory. Directories and files not properly formatted for jekyll will be left untouched for you to serve normally.

(read more: https://github.com/mojombo/jekyll/wiki/Usage)

Jekyll Configuration

Jekyll supports various configuration options that are fully outlined here: (https://github.com/mojombo/jekyll/wiki/Configuration)

Content in Jekyll

Content in Jekyll is either a post or a page. These content “objects” get inserted into one or more templates to build the final output for its respective static-page.

Posts and Pages

Both posts and pages should be written in markdown, textile, or HTML and may also contain Liquid templating syntax. Both posts and pages can have meta-data assigned on a per-page basis such as title, url path, as well as arbitrary custom meta-data.

Working With Posts

Creating a Post Posts are created by properly formatting a file and placing it the _posts folder.

Formatting A post must have a valid filename in the form YEAR-MONTH-DATE-title.MARKUP and be placed in the _posts directory. If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file. Additionally, each file must have YAML Front-Matter prepended to its content. YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.

Order Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy. Only reverse chronological and chronological ordering is supported in Jekyll.

Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.

Tags Posts can have tags associated with them as part of their meta-data. Tags may be placed on posts by providing them in the post’s YAML front matter. You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.

Categories Posts may be categorized by providing one or more categories in the YAML front matter. Categories offer more significance over tags in that they can be reflected in the URL path to the given post. Note categories in Jekyll work in a specific way. If you define more than one category you are defining a category hierarchy “set”. Example:

---
title :  Hello World
categories : [lessons, beginner]
---

This defines the category hierarchy “lessons/beginner”. Note this is one category node in Jekyll. You won’t find “lessons” and “beginner” as two separate categories unless you define them elsewhere as singular categories.

Working With Pages

Creating a Page Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do not start with an underscore.

Formatting In order to register as a Jekyll page the file must contain YAML Front-Matter. Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the site.pages array for inclusion into your templates.

Categories and Tags Pages do not compute categories nor tags so defining them will have no effect.

Sub-Directories If pages are defined in sub-directories, the path to the page will be reflected in the url. Example:

.
|-- people
    |-- bob
        |-- essay.html

This page will be available at http://yourdomain.com/people/bob/essay.html

Recommended Pages

• index.html You will always want to define the root index.html page as this will display on your root URL.
• 404.html Create a root 404.html page and GitHub Pages will serve it as your 404 response.
• sitemap.html Generating a sitemap is good practice for SEO.
• about.html A nice about page is easy to do and gives the human perspective to your website.

Templates in Jekyll

Templates are used to contain a page’s or post’s content. All templates have access to a global site object variable: site as well as a page object variable: page. The site variable holds all accessible content and metadata relative to the site. The page variable holds accessible data for the given page or post being rendered at that point.

Create a Template Templates are created by properly formatting a file and placing it in the _layouts directory.

Formatting Templates should be coded in HTML and contain YAML Front Matter. All templates can contain Liquid code to work with your site’s data.

Rending Page/Post Content in a Template There is a special variable in all templates named : content. The content variable holds the page/post content including any sub-template content previously defined. Render the content variable wherever you want your main content to be injected into your template:

...
<body>
  <div id="sidebar"> ... </div>
  <div id="main">
    {{content}}
  </div>
</body>
...

Sub-Templates

Sub-templates are exactly templates with the only difference being they define another “root” layout/template within their YAML Front Matter. This essentially means a template will render inside of another template.

Includes

In Jekyll you can define include files by placing them in the _includes folder. Includes are NOT templates, rather they are just code snippets that get included into templates. In this way, you can treat the code inside includes as if it was native to the parent template.

Any valid template code may be used in includes.

Using Liquid for Templating

Templating is perhaps the most confusing and frustrating part of Jekyll. This is mainly due to the fact that Jekyll templates must use the Liquid Templating Language.

What is Liquid?

Liquid is a secure templating language developed by Shopify. Liquid is designed for end-users to be able to execute logic within template files without imposing any security risk on the hosting server.

Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with your site and post/page data.

Why Do We Have to Use Liquid?

GitHub uses Jekyll to power GitHub Pages. GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.

Liquid is Not Programmer-Friendly.

The short story is liquid is not real code and its not intended to execute real code. The point being you can’t do jackshit in liquid that hasn’t been allowed explicitly by the implementation. What’s more you can only access data-structures that have been explicitly passed to the template.

In Jekyll’s case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins. Both of which cannot be supported by GitHub Pages.

As a programmer - this is very frustrating.

But rather than look a gift horse in the mouth we are going to suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.

Aside My personal stance is to not invest time trying to hack liquid. It’s really unnecessary from a programmer’s perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code) you are better off sticking with ruby. Toward that end I’ve built Mustache-with-Jekyll

Static Assets

Static assets are any file in the root or non-underscored subfolders that are not pages. That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages.

Static assets should be used for images, css, and javascript files.

How Jekyll Parses Files

Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.

• Content parsing. This is done with textile or markdown.
• Template parsing. This is done with the liquid templating language.

And thus there are two main types of file formats needed for this parsing.

• Post and Page files. All content in Jekyll is either a post or a page so valid posts and pages are parsed with markdown or textile.
• Template files. These files go in _layouts folder and contain your blogs templates. They should be made in HTML with the help of Liquid syntax. Since include files are simply injected into templates they are essentially parsed as if they were native to the template.

Arbitrary files and folders. Files that are not valid pages are treated as static content and pass through Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.

Formatting Files for Parsing.

We’ve outlined the need for valid formatting using YAML Front Matter. Templates, posts, and pages all need to provide valid YAML Front Matter even if the Matter is empty. This is the only way Jekyll knows you want the file processed.

YAML Front Matter must be prepended to the top of template/post/page files:

---
layout: post
category : pages
tags : [how-to, jekyll]
---

... contents ...

Three hyphens on a new line start the Front-Matter block and three hyphens on a new line end the block. The data inside the block must be valid YAML.

Configuration parameters for YAML Front-Matter is outlined here: A comprehensive explanation of YAML Front Matter

Defining Layouts for Posts and Templates Parsing.

The layout parameter in the YAML Front Matter defines the template file for which the given post or template should be injected into. If a template file specifies its own layout, it is effectively being used as a sub-template. That is to say loading a post file into a template file that refers to another template file with work in the way you’d expect; as a nested sub-template.

How Jekyll Generates the Final Static Files.

Ultimately, Jekyll’s job is to generate a static representation of your website. The following is an outline of how that’s done:

1. Jekyll collects data. Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.

2. Jekyll computes data. Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one big site object that holds all the posts, pages, layouts, and respective metadata. At this stage your site is one big computed ruby object.

3. Jekyll liquifies posts and templates. Next jekyll loops through each post file and converts (through markdown or textile) and liquifies the post inside of its respective layout(s). Once the post is parsed and liquified inside the the proper layout structure, the layout itself is “liquified”. Liquification is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.

4. Jekyll generates output. Finally the liquid templates are “rendered”, thereby processing any liquid syntax provided in the templates and saving the final, static representation of the file.

Notes. Because Jekyll computes the entire site in one fell swoop, each template is given access to a global site hash that contains useful data. It is this data that you’ll iterate through and format using the Liquid tags and filters in order to render it onto a given page.

Remember, in Jekyll you are an end-user. Your API has only two components:

1. The manner in which you setup your directory.
2. The liquid syntax and variables passed into the liquid templates.

All the data objects available to you in the templates via Liquid are outlined in the API Section of Jekyll-Bootstrap. You can also read the original documentation here: https://github.com/mojombo/jekyll/wiki/Template-Data

Conclusion

I hope this paints a clearer picture of what Jekyll is doing and why it works the way it does. As noted, our main programming constraint is the fact that our API is limited to what is accessible via Liquid and Liquid only.

Jekyll-bootstrap is intended to provide helper methods and strategies aimed at making it more intuitive and easier to work with Jekyll =)

Thank you for reading this far.

Next Steps

Please take a look at or jump right into Usage if you’d like.

Day 1: Getting Started With R

Here’s why I’ve started learning R:

</span>

Day 1: Getting Started With HTML

10 Lessons I Learned From Designing An Online Community Using WordPress and Buddypress

I re-discovered my fascination with online community building around the same time I subscribed to a shared hosting service, installed WordPress, discovered the Buddypress plugin, and stumbled upon some awesome code discussion forums online. This was December 2010. The discovery turned into an independent study I dubbed “Volunteerism in a Web 2.0 World,” which turned into the development of a website and lots of meetings and several pages of an annotated bibliography — all of which I submitted to my Research in Practice Program (RIPP) advisor at the end of the semester.

Over the course of my meetings with “stakeholders” (Duke students and administrators) to asses the value of the “website” (an online social network for Duke civic engagement), I learned a few things about designing an online community using WordPress and Buddypress.

1) Your site needs an FAQ.

No, really. It does. Although you personally might think that the activity feeds and groups and profile editing links are in the most obvious locations in the world, your users will not. They’re used to their own oft-frequented social networks (cough, Facebook), and  they’ll ask you why clicking on their avatar doesn’t automatically bring them to a “change your profile picture” page or if logging into your site using Facebook Connect will mean that everything they post will automatically get cross-posted to their Facebook wall. In addition, users want to know about your site features. How does your specific network make project management or content sharing easier than expected, for example?

2) Speaking of Facebook Connect…

Do it. People hate creating new passwords for new sites they’re not certain they’ll visit twice. The only caveat I have is that some people are suspicious of entering their account information into any third-party site. Therefore I recommend giving people single sign-on options using Twitter, Linkedin, OpenID, Livejournal, etc. as well as Facebook.

3) Learn HTML and CSS. Understanding PHP wouldn’t hurt either.

Trust me — it helps a lot to know HTML and at least some basic CSS. (If you don’t know how to start, Google is your friend! There are so many free tutorials out there.) Understanding the style.css file is all you need to start changing the color, style, and positioning of the components of your theme. Along the way you’ll probably start staring at all the PHP… and be forced to understand it as well. :)

4) Excited volunteers =/= a successful community.

I approached a lot of people for feedback about my project, and a surprisingly high number were interested in getting involved. After happily accepting their support, nothing happened. Turns out there are two lessons to gleam here: 1) Figuring out how to manage volunteers in a way that also respects their time and their interests is difficult. 2) The people excited enough to volunteer are already sold on your product, so it’s important not to take their excitement too seriously. The rest of your target market still needs to be convinced to care about your community enough to join.

5) Make your homepage interesting enough to visit twice.

My landing page was static for the first few weeks. Then I tried to spice it up by embedding a dynamic Wix banner with pretty photographs and an inline menu that walked the user through all the features on the site. Then I realized hey, that’s still static and eventually figured out how to tweak the activity.php file (which contained the sitewide newstream, basically) and move it to the home page.

The point is, you want users to instantaneously be able to see new content that’s relevant to them every time they load up your page. There’s probably a reason Quora, Stackoverflow and most Ning networks all have news feeds on their front pages.

6) Clearly define your niche.

Even if your network shared some of the highest quality content on the internet, users aren’t going to come back to it when they can visit Google News or The New York Times for their daily news intake. It’s important to clearly define your site’s niche so that users will have an easier time understanding how your site adds value to their lives. For example, Quora is the social network where one gets their questions answered; Stackoverflow is a Q&A network for programmers; Linkedin is a specific network for jobhunting professionals. What specific need does your social network cater to?

7) Don’t be afraid to ask for e-mail addresses.

I initially suffered from a fear of spamming people. Then I realized that every site I’ve registered an account with has sent me a welcome e-mail. And then they keep on sending me monthly, if not weekly  newsletters. Why? To make sure I remember that they exist. Even Facebook, which has become an automatic “second window” for many users (the first, obviously, is e-mail) still e-mails out tons of annoying notifications and friendship search reminders to new registrants.

Moral of the story: as long as you give the user a clear “unsubscribe” or “manage preferences” link, you shouldn’t feel too bad.

8) Beware of outdated plugins and themes.

Look at the description closely and check to see if it’s been tested up to the WordPress version you’ve installed. If you’re unsure, search for the plugin forums (every WordPress plugin should have one) and see the latest praises or issues people are discussing on the threads.

9) If a new theme or plugin crashes your site, rename or delete it.

The first time I got a PHP error from a rogue plugin, I called tech support at my hosting company — who helpfully fixed the problem for me by asking me about the last thing I did (“Install a plugin,” I said) and going into my files to rename the plugin.

Eventually I learned how to use my hosting account properly by finding the files myself. -_-

10) Cook a stew, not a souffle.

Tony Brown, an entrepreneur and co-director of the Hart Leadership Program at Duke, gave me this valuable piece of advice when I cold-emailed him to request a meeting.  I had originally intended to obtain advice about how a social network that engaged Duke students could potentially also support non-profits in Durham (Duke-Durham relations were part of his domain). He told me to stop worrying about the details and to treat the project as a stew, not a souffle.

In other words: Focus first on gaining traction (Does the product add value? Will the targeted really use it?), and then worry about adding all the cool features, target market expansion, and awesome partnerships.

• Hi, I'm Linda! I enjoy going to tech meetups, learning web development, and blogging about the learning path. Follow me @LPnotes

• What I have been working on (UPDATE AFTER THREE YEARS)
• Notes from Strange Loop
• How to create multiple forks of a git repo
• Day 9: #100daysofcode
• Day 8: #100daysofcode
• Day 7: #100daysofcode
• Day 6: #100daysofcode
• Day 5: #100daysofcode
• Day 4: Random #100daysofocode
• Day 3: Random #100daysofcode
• 100daysofcode Challenge Diary Log
• The #100daysofcode Share-One-Thing-You-Learn Challenge
• SASSConf NYC Reportback (2014)
• On the road to competency – two tips
• Learning TDD
• Learning to code, but feeling lost? I interviewed some experts, and here’s what I found. (Part II)
• Learning to code, but feeling lost? I interviewed some experts, and here’s what I found. (PART I)
• How to volunteer in the NYC tech community with little to no effort (and gain a lot in the process!)
• Using VVV to develop multiple WordPress sites locally (alternative to using MAMP Pro!)
• Actionify the News
• Comedy Hack Day Reportback
• Quizzing Yourself Is The Best Way, Maybe? (More Learning-How-To-Code Revelations)
• Tech Meetup Appreciation Post (With Photos!)
• Re-reading Eloquent Javascript
• REVIEW: Getting Started with Django Video Series on Vimeo (Kickstarter-backed), Part I
• LEARNING TO CODE TIP: Find a Study Partner
• “It’s not that you’re not smart – it’s just that repetition is often what it takes.”
• More Python/Django Revelations
• May 2014 To-Do List
• RESOURCE: Querying your Django Web App Without Using SQL
• Installing Django With Virtualenv
• What I learned from participating in TechCrunch Disrupt’s 2014 Hackathon
• 10 Reasons I Encourage Friends To Go To Hackathons
• REVIEW: Coding for Entrepreneurs Video Series Tutorial (Build a Django App)
• Udacity’s Intro to Object-Oriented Programming Class
• REVIEW: Zed Shaw’s ‘Learn Python The Hard Way’ (Chapters 1-43)
• The Growth Stages of Reacting to Error Messages, Web-Developer Style
• OMG, I got a two-gold-star-difficulty question on Udacity right!
• Well played, AlleyNYC: Free Tech Co-Working on Sundays!
• Feeling like an idiot
• Be a Creator, not a Consumer (also: some advice about choosing what to study in college)
• Javascript vs. Python: Simple Naming Differences
• Learning Python the Hard Way
• Neat, short (20 minute) introduction to AngularJS + Firebase
• Yes, Coding Can Be Fun
• W3 Validator is a lifesaver
• The Biggest Mistake You Can Make While Learning How To Code
• Some Thoughts on Human Invention
• Calling myself a front-end web developer
• Never going back after git
• Reflections on Write-Speak-Code NYC – June 20th-22nd 2013
• Using the “not” selector in jQuery
• How to write a good bug report
• Front-end vs. Back-end
• Thank goodness I save all my bug solutions in e-mails
• Notes from Seattle Tech HN Meetup — Speaker: Justin Kan
• Finding text in a particular file using grep
• Deploying to Heroku
• Configuring the terminal to open Sublime Text files with the ‘subl’ command
• Teaching a beginner Lessons 0 and 1 of Zed Shaw’s Learn Python The Hard Way
• Someone once asked me…
• Zed Shaw is amazing
• A nice cheatsheet for creating graphics for social media
• The Coding Diaries: Spring 2013 Resolutions
• Chrome Developer Tools, where you have you been in my life?
• Why I’m Falling More And More In Love With Sublime Text
• Book Review: “The CSS3 Anthology” by Rachel Andrew (5 Stars)
• First impressions of CodeSchool’s jQuery: First Flight
• The light bulb moment for me…
• ‘Sublime’ (The Text Editor) Is Pretty
• How I Converted To Mac From PC
• Hacker News Readers, You Make Me Laugh
• Erm. Hi. FTP.
• Note To Self: Remember To Close Tags
• REVIEW: HTML and CSS Book by Jon Duckett
• Did you know you can preview your randomly saved .html and .php files on your web browser?
• Some Day I’m Going To Make A Scrolling Infographic Page Like This Too
• Things I Should Have Figured Out Earlier, But Didn’t Until People Talked To Me
• My Set-Up Environment For Learning From Tech Books
• “No Thanks, You Don’t Deserve It.”
• What I’m Learning From TutsPlus.com’s jQuery In 30 Days E-mails (Free)
• How To Magnify A Graphic In 5 Steps (The Beginner jQuery Way)
• Magic
• Small Lesson
• A 30-Minute Youtube Talk On Data And Design
• Lessons Learned From Beginner jQuery Fail
• Photoshop! Finally.
• How To Get Started With CSS
• Why Your CSS and Javascript Might Not Be Working In Your WordPress Post
• Day 2: Resizing Images For The Blog
• Resource: John D. Cook’s Intro. To R For Programmers
• Day 1: The Difference Between WordPress.org and WordPress.com
• Source Control: How I Discovered Its Importance The Hard Way
• Learning How To Code ==>> Saving The World. Sort Of. Well, It’s A Possibility.
• Jekyll Introduction
• Day 1: Getting Started With R
• Day 1: Getting Started With HTML
• 10 Lessons I Learned From Designing An Online Community Using WordPress and Buddypress