RebootJeff.com

Try. Learn. Repeat.

Welcome to RebootJeff.com

I’m a JavaScripter writing about web software development. I write about other interests too.

Tennis, cars, videography, music, composition of the universe, the aesthetics of everything, and Batman tend to be on my mind as well.

Navigation

Find me on

My Sublime Text 2 Setup and Customization

- - posted in customization, dev tools, software development | Comments

Updated on August 8, 2014.

I use Sublime Text 2 as my text editor for coding. I don’t use a fancy IDE like WebStorm, but I do plan on trying out WebStorm more at work. Actually, I should probably upgrade to ST3, but for now, I’m happy with ST2.

Config

However, ST2’s light weight comes at a cost: you probably need to configure some stuff before you’re really ready to roll. Here’s what I do when I first install ST2 on a machine.

Key Bindings

First, I change the keyboard shortcuts for cycling through open tabs. The default behavior is based on your usage history (most recently viewed tabs), but I prefer just cycling from left to right. There’s actually another key binding that can cycle tabs from left to right, but I prefer using Ctrl+Tab.Therefore, I edited my key bindings like so…

Preferences > Key Bindings – User
{ "keys": ["ctrl+tab"], "command": "next_view" },
{ "keys": ["ctrl+shift+tab"], "command": "prev_view" },

Settings

Next up, I make sure my whitespace is configured to my liking. I think most coders who lift hefty amounts of JavaScript go with indentation 2 spaces at a time, so that’s what I do. I prefer it because it takes up less space than a typical 4-space tab, which is critical when viewing code in split-screen mode. I also like having the option to manually change indentation with spaces if necessary for alignment purposes. Mixing spaces and tabs gets messy.

I also configure Sublime Text to automatically add a new line at the end of every file whenever I save. It won’t add a new line if one already exists at EOF. I personally never suffer from lack of new line at EOF, but some UNIX tools won’t work without them, and I know lots of hardcore coders out there like using such tools. I don’t want to screw them over. With that said, allow me to present my ST2 settings…

Preferences > Settings – User
// The number of spaces a tab is considered equal to
  "tab_size": 2,

 // Set to true to insert spaces when tab is pressed
  "translate_tabs_to_spaces": true,

// Set to true to ensure the last line of the file ends in a newline
// character when saving
  "ensure_newline_at_eof_on_save": true,

Theme (UI Skin)

I use the Nexus theme, which you can find here: https://github.com/EleazarCrusader/nexus-theme. The readme file explains a bunch of different installation options, but I recommend installing via Package Manager. The readme also tells you how to activate the theme after installation.

official Nexus theme screenshot

The orange and blue decorations on the tabs tell you if the file has been change since last save.

Packages

Sublime Text doesn’t come with many bells and whistles. Instead you add them as packages. First, you must install the package manager by following these instructions. After that, get ready to discover a giant pool of all the bells and whistles you could possibly want. If you need to adjust the settings for any of these packages, you can usually find good documentation from the readme files of their respective GitHub repos.

After you install Package Manager, you can access it by hitting Ctrl+Shift+P (or perhaps Cmd+Shift+P for Macs?) and then typing “package control” into the search box. The typeahead will reveal your various options, but you mostly be using “Package Control: Install Package”. There will be some load time necessary to provide you a list of available packages, but after it’s done, you can search for packages by name. Installation will similarly require some load time. Check the bottom-left of the ST2 window to see relevant status messages.

Here are the packages I installed:

Alignment

Prettify your code by aligning multiple lines of variable definitions and hash objects. For example…

Before and After using the Alignment package
// this stuff...
var x = 123;
var foo = 'bar';
var exampleObj = {
  my: x,
  name: 99,
  is: 'Jeff'
};

// would turn into this stuff...
var x          = 123;
var foo        = 'bar';
var exampleObj = {
  my  : x,
  name: 99,
  is  : 'Jeff'
};

This may look stupid to you, but I don’t use it all the time. The main place I like to use it is with multiple var example = require('npm package name here'); statements at the top of a JS file. By the way, I had to edit the package settings to get alignment for object literals. I added the ":" seen below…

Preferences > Package Settings > Alignment > Settings – User
{
  // The mid-line characters to align in a multi-line selection, changing
  // this to an empty array will disable mid-line alignment
  "alignment_chars": ["=", ":"]
}

GitGutter

Add indicators in your gutter so then you can see which lines of code have been changed since the last git commit. See the left edge of this screenshot: GitGutter in action

SublimeLinter

I prefer live linting over build-time linting. SublimeLinter supports a ton of languages, and I have it set to simply bring up an indicator in the gutter and some underscores to point to any issues it finds. It’s not too obtrusive.

TrailingSpaces

Extraneous whitespace is bad. Trailing whitespace is worse. I use this package to highlight any trailing whitespace in bright pink. I bet I could set my linter to do this, but oh well.

MarkdownEditing

Who doesn’t love Markdown? It makes GitHub README files and wiki pages look great. It makes dev blogs look great. It makes writing dev-related text easy. Sometimes, I write rough drafts of blog posts within Google Docs or Dillinger, which is a sweet online Markdown editor. In the end, I always complete my blog posts by writing Markdown within Sublime Text.

I recently found a sweet ST package to help edit Markdown files: MarkdownEditing. It completely transforms the look and syntax highlighting of your Markdown. Sadly, I use CodeRay for codeblocks rather than standard Markdown markup. So MarkdownEditing can’t beautify my codeblocks within Sublime Text, but inline code snippets like this one are highlighted in a very helpful way. You can see all the ways that the package alters your Markdown here. Keep in mind that there are a couple other themes available specifically for MarkdownEditing. I use the dark theme of course.

Syntax

You might also find it handy to install packages for specific languages. For example, I dabble with CSS pre-processors and templating languages. I’m currently checking out LESS for CSS and Jade for HTML, so I’ve installed syntax highlighters for them. The package names are simply “LESS” and “Jade”.

[HackR Diary] Weeks 11-12: And Beyond!

- - posted in Hack Reactor, HackR Diary, coding bootcamps | Comments

Now We Boogie

The Flash suggests rhythmic celebration – Image by Yale Stewart of JL8 Comic

The events discussed in this blog post occurred in December 2013 and January 2014 because a blogging hiatus caused a bit of a delay. Plus, I’ve just been lazy with blogging recently.

Recap of Events

My “final” two weeks at Hack Reactor weren’t really final. As explained in a Quora post of mine, I continued going to Hack Reactor for additional lectures and learning exercises AFTER graduation.

Weeks 11 and 12 were all about preparing for job hunting and prepping for hiring day by practicing presentations. These are definitely the least intense weeks of the program. Some students were motivated enough to start new projects. Some students (like me) spent some time to refactor code from our Hack Reactor projects from weeks 6-10. Throughout the final two weeks, we received a wide variety of lectures on how to find a job, on how to approach whiteboarding, and on a few different tech topics too. Most of these lectures were only an hour, and many of them didn’t have tightly associated classwork (which is unlike the first half of the program).

One thing I found odd was the emphasis that staff put on downplaying Hack Reactor when job hunting. I’m not the only one to feel funny about it. The reason is that you don’t want employers to frame their perspective of you within the confines of “recent student.” I can understand that, but I didn’t bother editing my blog to avoid “exposing” myself as a recent graduate of a training program.

Unfortunately, the final stages of the Hack Reactor curriculum ran into issues. Fortunately, Hack Reactor managed to pull together the resources to compensate. I explain later in this blog post.

Pamela Fox Discusses Engineering Culture

One of my favorite guest speakers during my time at Hack Reactor was Pamela Fox. Pamela already gave a talk at Hack Reactor, but it was a more technical talk about Backbone. This time around, she gave a talk about the culture of professional software engineering. It was a great presentation that discussed what commonalities and differences you can expect to see when comparing engineering teams. A lot of what she said ended up influencing the questions I ask employers when searching for a job.

Consultant Surveys the Students

For the first time in Hack Reactor history, a consultant was brought in specifically to give a 2-day workshop on job search prep. The consultant, David Daniels, did all the usual stuff like resume review (which would make him the 5th person to review our resumes during the job search prep portion of Hack Reactor), but he also conducted exercises on networking and personality testing. Plus, he gave a lecture about what companies like Microsoft look at when evaluating candidates.

Networking Practice

“Tell me about yourself” is such a common opener for job interviews (especially in the phone screen stages), but it’s funny how hard it can be to come up with a coherent answer without any practice. Therefore, David had us all practice giving quick, autobiographical pitches that would not ony sound concise (no rambling!), but also provide all the relevant info that recruiters want to hear (what you’ve been working on, what specific skills you have, what you look for in a new job, etc).

Students were also instructed to practice giving “pitches” on why they want to work for company XYZ in response to the frequently asked question of “Why do you want to work here?” Admittedly, this is something I did not give much attention to after graduation, and I regret that. It’s definitely important to practice answering that question for all the different companies you apply to.

Strengths Finder Personality Test

The other major activity conducted by David was post-survey analysis. What survey? The Strengths Finder survey. It’s a personality test that focuses on your “strengths” in a way that is supposed to help you inspect your personality in a way that is relevant to professional/work life.

My Results

Here are my top 5 (paraphrased) strengths according to the test:

  • Input: Craving to know more. “Input” folks like to collect and archive all kinds of info.
  • Analytical: Tendancy to search for reasons and causes. “Analytical” folks think about all the factors that might affect a situation.
  • Responsibility: Taking ownership psychological of what they say they will do. “Responsibility” folks are committed to stable values such as honesty and loyalty.
  • Restorative: Strong problem solving. “Restorative” folks figure out what is wrong and resolving it.
  • Intellection: Characterized by intellectual activity. “Intellection” folks are introspective and appreciate intellectual discussions.

My results put me in the “typical” engineer group. Together, with the fellow students with similar strengths, we built a Google Spreadsheet to further analyze our results and find out who was most similar to whom. Damn. We nerdy.

Mini-Anti-Personality-Test-Rant

I’m not a fan of personality tests. Any one who has taken an intro psych class knows that personality tests are often flawed by the wording of the questions, the limited options provided by multiple-choice formats, etc. On top of that, I don’t like the effect that personality tests have. There’s a lot of confirmation bias. Test takers tend to allow the results to define them as a self-fulfilling prophecy. When people learn of other people’s test results, they might end up pigeonholing each other. “Oh that test said you have a tendency to over-analyze situations? I should call you out on it whenever you offer criticism.” (Ok that last hypothetical example is a bit melodramatic, but it’s the type of crap that starts happening on conscious and subconscious levels)

Perhaps what I despise most is that personality tests can solidify self-perceptions and stifle personal change as a result. I believe people can change. They change all the time. This is not optimism. I believe people change for the better and the worse all the time. My point is that some fools take personality tests and believe the results always involve immutable properties. Such belief is more ridiculous than using programming jargon to discuss psychology concepts ;)

Graduation

There was booze, dancing, food, funny photos, and good times :D

Overtime Support

The day after graduation (which was in late December), my cohort returned for a follow-up. The follow-up included asking us not to reveal too many of Hack Reactor’s trade secrets, asking us for feedback about the course, and some extra heartfelt moments.

Then we parted ways. Some flew back home, never to return. Most of us went home for the winter holidays and returned in January for post-graduation job search help. This included mock interviews conducted by Hack Reactor staff (more specifically, Cameron Boehmer, an awesomely nice guy who created Squirt.io). It also included practicing whiteboarding with peers, lots of mentoring, and a few additional lectures about stuff like user authentication and SEO.

Presentation by Gayle Laakmann

The author of the mucho famous book, Cracking the Coding Interview, gave a talk at Hack Reactor in January. She gave a ton of great advice. I will regurgitate much of it in a future blog post. For now, I just want to share the most interesting tidbit.

Gayle mentioned that you will suck at surmising your own interview success. Apparently, surveys have been conducted, and they reveal zero correlation between how well a candidate thinks they did versus how the candidate’s interviewer thinks they did. You may think you aced an interview, but you actually said something that’s a deal-breaker. Or you may think you bombed, but you actually did better than all the other candidates.

Hiring Day

Unique to my cohort, hiring day was hosted at Hack Reactor after graduation. We presented group projects in front of an audience of 15 or so companies. We then went into a mini-interview marathon akin to speed dating. Each Hack Reactor student got a chance to speak with about 7 or 8 companies based on preferences submitted to Hack Reactor staff beforehand. After the crazy “speed dating”, there was an open networking session (basically a happy hour). There was a lot of stress leading up to this day, but ya know what? It really wasn’t that bad.

I would say about 1/3 or 1/2 of my peers who participated actually got hired by the companies that showed up. For me, hiring day was just the beginning of a nearly-3-month-long search.

I should (re-)mention that about a third of my cohort didn’t actually participate in hiring day because they weren’t interested in starting a new job soon or they had joined Hack Reactor’s Hacker-in-Residence program.

Job Searching

As you can imagine, I have a lot to talk about with regards to job searching. I’m excited to blog in detail about the ups and downs of the search. To cut to the chase, let me mention that I am fully employed. I’m a professional software engineer working on a web app that uses full-stack JavaScript. I don’t mean to brag (much), but the gig is pretty friggin’ sweet. Hack Reactor was a success!

What I Learned

I learned so much about job hunting. I will go into details in a future blog post, but for now, I will outline some of what I picked up when searching for a job:

  • Job Sites
    • What different job sites to use
    • How to use them differently
    • Which sites are more effective
  • Job interviews
    • What kinds of questions to ask
    • What kinds of questions I will be asked
    • How to communicate for an interview
    • The role of good/back luck
  • Regrets
    • I should’ve used more Hack Reactor connections
    • I should’ve taken more action sooner
    • I should’ve actively shown more enthusiasm for each company I visited
  • General
    • What recruiters are really like
    • How employers evaluate you before any interview

What’s Next for Hack Reactor?

Yesterday, I went to my cohort’s “3-month” reunion hosted by Hack Reactor. It’s actually been closer to 5 months since graduation, but whatever. At the reuinion, the founders of Hack Reactor did a Q&A panel where they provided career advice and asked us how things were going at our new jobs. After the panel, we were told that Hack Reactor HQ is expanding. It’s already expanded once since my cohort ended by using a second floor of the building. That expansion increased the size of Hack Reactor cohorts. More staff have been hired too.

A third floor will be opening in June. It will mostly be used as offices for the newly augmented staff, but it will also have a new lounge area for alumni to use! Niiice. Wheels have been set in motion to organize alumni events and general activity. For example, there are plans to use the alumni network as an avenue for project collaboration (e.g., Feel like starting a random side project? Get ideas and possibly form a team with alumni).

[HackR Diary] Weeks 8-10: No More Solo

- - posted in Hack Reactor, HackR Diary, coding bootcamps | Comments

something something Mighty Ducks

Insert inspirational metaphor relating birds to teamwork

Junior-to-Senior Transition

As I mentioned last time, my HackR Diary was on hiatus for a bit, so the events described in this blog post occurred back in mid-November thru early-December of 2013. Weeks 8, 9, and 10 of my Hack Reactor experience covered a group project period where students formed small teams to create web apps from scratch.

I forgot to mention a few points in my description of the personal project period:

Client Projects

Some folks in my cohort accepted client projects rather than coming up with their own web app ideas. This meant they had to meet with clients, deal with external requirements, etc. Some had fun experiences; some had frustrating experiences. Some got paid; some volunteered. They all got to add some extra gravitas to their resumes/CVs.

Being a Senior

The cohort before mine graduated from the program just before interim week. After interim week, my cohort returned to HR HQ to find a new “junior” cohort, and there was a transition to seniorhood for us. As a senior, you have fewer/shorter lectures, less guidance, and you’re given more freedom to explore on your own. You still have a schedule to follow, but it’s far less rigid, which is fantastic. It’s funny how you feel more freedom, yet you end up working harder because of the nature of project periods at Hack Reactor.

Unfortunately, there isn’t much time to get to know the juniors when you’re a senior. We had one code review night where seniors gave juniors feedback on their classwork, but as a senior, your mind is always worried about your project, your app, your baby born of code.

By the way, I noticed that the juniors had more diversity. They had more women and more minority folks. I’m not saying my own cohort felt shitty because of the percentage of white males, and I’m not saying the new junior group reached some sort of ideal diversity (eventually, I may write a rambling blog entry about my views on diversity). I’m just noting the “slope” created by two “points of data.” The junior cohort was larger by about 5 or so people, but the increase in diversity was still noticeable. That said, I also noticed Hack Reactor felt more crowded (doh!).

Recap of Events

I teamed up with 3 of my fellow seniors to work on a smartphone game called Phone Tag. Gameplay is like a free-for-all laser tag. Players sneak up on one another and hit a button to tag. The game displays a map (via Google Maps) to show locations of other players, power-ups, respawn points, etc. The app consists of HTML, CSS, and full-stack JavaScript. The client app is “ported” into an iOS app and an Android app via a tool called PhoneGap. Phone Tag leverages geolocation and real-time communications.

The first week just consisted of setting up boilerplate code and brainstorming game ideas. It took us awhile to settle on the free-for-all game mode. We originally considered implementing a game resembling zombie tag instead. My team also had to spend lots of time researching libraries, tools, smartphone abilities, and all that sort of goodness to find out what we should use to develop our project.

Fitness Challenge: Push-Up Routine

I’m sure some Hack Reactor folks (Hackers React? Hacker Reactions?) cynically roll their eyes at the staff’s efforts to promote health, but I appreciate them. For one week, there was a push-up challenge where students were encouraged to pair up and hold each other accountable for completing a set of push-ups twice a day. I paired up with a junior, and it was cool to be able to get to know someone outside of my cohort.

Hacker-in-Residence Program

In the middle of the group project period, the staff told seniors about a program to extend the Hack Reactor experience. The Hacker-in-Residence program is an extra 3 months where you get paid to work part-time for the institution (develop internal tools, teach beginner-level content, interview applicants, etc) and work on more projects (i.e., extra project periods). The idea is that a select few seniors can become Hacker-in-Residence and gain valuable experience. I chose not to apply for the program because I already felt well prepared to enter the job market. Many students felt the same way, but plenty of them were attracted to the HIR program. Under half of the seniors applied, and most of them were accepted.

Therefore, about 1/3 of my cohort became HIRs. It’s important to note that Hack Reactor might not include these guys in their post-graduation employment stats. But even so, I know previous HIRs have had little to no trouble getting employed after their HIR phase ended.

New Hack Reactor Admissions

At some point during weeks 8-10, Hack Reactor launched their new website. It’s quite a bit nicer than their last version, but more interestingly, they changed their admissions process too. The new process uses their website to check very basic JS skills.

Hack Reactor likes having students/alumni contribute to their official blog, and I anwered the call for volunteers by authoring this blog post about the admissions process. Sadly, much of my experience lost relevance when the staff produced a new admissions process. I had to go through a 2-stage interview process, but now there is only a single interview. However, I think a lot of the advice I provided still makes sense.

What I Learned

Much like the personal project period, a lot was learned via trial-by-fire work during the group project period. My group tried and scrapped various features, libraries, tools, project management strategies, etc. It was so tough and so awesome at the same time.

Tech

My team knew we wanted to use geolocation, but we weren’t certain about much else. This meant that we had to research and explore many options. Eventually, we settled on a tech stack featuring quite a few different libraries/tools.

PhoneGap

I spent a lot of time wrestling with PhoneGap, a dev tool for creating smartphone apps using tech normally reserved for web browsers. It’s a fairly popular option for informational smartphone apps, rapid prototyping, etc. However, 101 out of 62 doctors have concluded that PhoneGap can lead to headaches and irritable demeanor. I’ve written specifically about using PhoneGap for Android in a past blog post.

Don’t use jQuery animations

This article explains animation options quite well, but the gist of it is that you should avoid jQuery animations. You can use CSS (if you love jQuery, then use it to add animation-centric classes to target elements) or faster JavaScript animation libraries like GSAP (but it’s not very famous?). For Phone Tag, my team originally tried doing simple slide animations via jQuery-Mobile, and the performance was horrible. We switched to CSS-driven animations because there’s plenty of online help for them and we knew it would be good for us to study more CSS anyway.

Engineering and Project Management

Everyone expects to learn plenty of technical stuff when building projects at Hack Reactor, but there’s a slew of non-technical wisdom discovered too. My team had a lot of discussion and debates regarding feature sets, client vs server roles, project priorities, division of labor, etc. as we worked to meet MVP (minimum viable product) milestones and deadlines.

Unlike the personal project period, the group project period involved a ton of communication. There’s a huge amount of extra planning and talking that goes into group coding. The collaboration is great for producing cool ideas and reducing scope of work for any given individual, but the group setting necessitates expressed justification for actions. When you’re on your own, you just explore and debug however you want to, and you’re often making heavy use of your working memory. When you’re in a group or even just a pair, you often have to explain before you act, which is a pretty serious exercise for your brain because it can feel like your working memory doesn’t get to operate at peak efficiency due to the extra steps of communication that fall between coming up with a small idea and implementing that idea.

Another way to put it: when you’re going solo, you get comfortable with the just try XYZ and see if it works model for programming. When you’re part of a team, you often need to explain XYZ, process any critical feedback you may receive, etc. Transitioning from solo work to group work needs a major change in mental processes. Luckily, everyone in my team is more patient and laidback than I am, so no wars broke out and no debates devolved into chaos. Good times.

[HackR Diary] Weeks 6 and 7: App From Scratch

- - posted in Hack Reactor, HackR Diary, coding bootcamps | Comments

Personal Project presentation time

Presenting my project, Co-Compare, to the folks of Hack Reactor

Life Update

I got a job! I will start using my JS skills for dolla bills on Monday. I will blog all about my rather tiring job search soon. For now, I will resume blogging about Hack Reactor from where I left off. During the 2nd half of the program, I didn’t do any blogging, but I took plenty of notes for the sake of blogging at a later time, so prepare to be amazed …or mildly amused. Remember, the following rollercoaster ride took place during late-October through mid-November.

Recap of Events

Interim Week (different format)

The 2nd half of Hack Reactor starts with an “interim week” (aka “solo week”) where expectations are a bit cloudy. The Hack Reactor website didn’t do a good job of explaining that the injection of an interim week means that Hack Reactor is really a 13-week program. During this special week, Hack Reactor HQ is not guaranteed to be open to students. Also, students are not guaranteed any access to staff. The staff is either taking a break or working on reconfiguring the offices or other changes.

In other words, the students are on their own for starting the first week of developing their personal projects. Students self-organize if they want to meet up at a cafe or whathaveyou to enable collaboration.

What I Did

  • I spent most of my time working from HR HQ when it was open. I used nearby cafes when it wasn’t.
  • Like a few others, I used interim week to do some travelling and to catch up on sleep.
  • At one point (maybe after interim week?), I broke my laptop by being a Linux noob. I was one of few Ubuntu users in my cohort, and I had trouble dealing with permission/access issues. I eventually followed some StackOverflow suggestion and fucked up my permissions so badly that I had to reinstall Ubuntu. As you can imagine, my emotions are still failing to heal from that self-inflicted disaster.
    • FYI, my new job is giving me a Mac. Soon I will join the majority of devs in the promise land of screens that actually reproduce accurate colors, impressive battery life, and installation wonders such as homebrew.

Extras

  • In my cohort, we organized a night to go to a movie theater for Ender’s Game. Good times.
  • A rep from Famous stopped by to give a presentation about a brand new web app framework. It’s so new that even now, Famous is in beta. Back during the personal project period, it was in a closed beta (or was it alpha?), but Famous was inviting Hack Reactor students to access it! The framework renders special <div> elements in a breathtaking way. I never used it, but I will talk about it a bit more in another blog post.

What I Learned

Holy. Crap. I learned so much during the personal project weeks. Admittedly, I didn’t work extra long hours until the last week or so before the deadline. By then, I was working at least 80 hours per week. In the first couple of days, I realized there was so much I had to learn that it felt quite overwhelming, and I had a difficult time starting.

Tools

Obviously I would have to learn a lot of app concepts, engineer some solid logic, etc. But I also had to do all this while learning new tools.

  • Balsamiq: Wireframing software. Creating wireframes really helps when trying to explain what you hope to build. To practice communication skills and project management, students had to explain their progress/goals very briefly during small stand-up meetings.
  • Yeoman: Boilerplate/scaffold generator. I used an Angular-Express generator to help me get started making a full-stack app with boilerplate code for Angular, Node, and Express. This served as a great “starter pack” of code.
  • Grunt: Task runner. To be honest, I used Grunt simpy because it came with Yeoman. However, gaining exposure to the tool opened my eyes to the possibilities provided by task runners like Grunt.
  • Stylus: CSS pre-processor. I’m not sure if CSS pre-processors are part of the tech stack or “just” another set of dev tools, but for what it’s worth, I didn’t write pure CSS for Co-Compare. Instead, I wrote Stylus CSS. I like the visual design side of front-end development, and using Stylus made that facet even more fun.
  • Heroku: Web app hosting provider. It’s easy to use because it follows a git workflow, but deployment still has challenges (re: environment configuration).

The Tortured (ok not really) Birth of An Idea

I like to think my mind is superior –errr…I mean creative. However, it can be tough to come up with web app ideas based on constraints. Everyone worried about whether or not they could actually implement their ideas in just a few weeks (I think it amounted to only 2.5 weeks). In the end, I learned that “Just Do It” really applies. You can spend roughly 3 gajillion hours analyzing ideas, use cases, market needs, tech stacks, visual design, etc. But at some point, you need to just do it already. Just make something and see what happens. The price of failure is time spent. The gain of failure is lessons learned. A beauty of programming is the ability to quickly change, pivot, redo, etc.

From Cool to Meh

Originally, I thought my idea was too boring. I wanted to create a fantasy sports game specifically for tennis, but I couldn’t find a good way to get the data/stats from pro tennis matches, so I switched to something far less cool.

I switched to an idea spawned by my love for analyzing/comparing products and services. In the past, I’ve spent far too much time comparing video game consoles, cars, computer parts, bootcamps, etc. I enjoyed it too. A lot. But I knew most people aren’t crazy in this way, so I worried that my app idea for Co-Compare (a web app to build comparison tables and have others vote on them) was too unsexy.

From Meh to Oooh

It’s true that Co-Compare doesn’t have a ton of wow-factor, but it provided plenty of opportunity:

  • Simplicity: It was the type of idea that could work with very few features (good for rapid prototyping).
  • Exploration: But I could have fun adding more and more features as I desired. There were plenty of sub-ideas to explore and keep my brain satiated with more goodies to engineer.
  • Fundamentals: My app requires CRUD actions. Create, Read, Update, and Delete are fundamental app actions that devs should know. It’s weird to “brag” that Co-Compare helped me learn fundamentals, but it’s important, and it’s not easy just because it’s “fundamental.” Engineering a CRUDy app is a great learning experience.
  • Full-Stack: My app covered a lot of territory so it exposed me to CSS pre-processors, front-end MVC, API design, databases, user authentication, etc. This was really scary at first, but afterwards, I was truly proud of what I covered.

I really believe that the full-stack nature of Co-Compare solidified my abilities as a web app developer. By creating a nice-looking front-end, my own API, and back-end models for a SQL datastore, I learned so much that it gave my confidence a tremendous boost –which is funny because I had a ton of confidence going into the personal project weeks…then I lost a lot of confidence when nothing I created worked the first time. So at the end, I regained a lot of confidence that I already had at the beginning.

Note: Some of my classmates implemented ideas that had very bare front ends because all the impressive stuff was run on the server side. Other folks created apps that had little or no back-end logic. The number of things wrong with these paths is quite small. In fact, most experts would say the number rhymes with “hero.” Anyway, my point is that this particular “full-stack” facet of my experience is not the “best” way, but just something that I really value for myself.

Dev Cycle/Process

Hack Reactor staff helped students with their projects by giving recommendations on tech stack decisions, dev tools, deployment options, etc. And of course, they gave us debugging help, but there was no hand holding.

The primary form of guidance came in the form of some project management structure. We formed small groups that held its members accountable for short-term goals. The staff taught us about iterative development and the concept of creating MVPs (minimal viable products) as milestones rather than aiming for creating versions that were 100% complete.

In other words, I learned about some dev processes to help promote productivity as a software engineer.

Want to Learn from My App?

You can find the code for Co-Compare on my GitHub. I took the time to write up a decent README too because for some reason, I have a good time writing English in addition to JavaScript. I suggest you check this out if you’re interested in learning more about how I created an app from scratch.

Keep in mind that you shouldn’t follow everything I do. For example, my Angular app folder structure neglects best practice. It was a popular structure at the time, but it’s actually best to name folders based on features, rather than just lumping all controllers together, all views together, etc.

Setup for PhoneGap for Android for Reals

- - posted in Android, PhoneGap, development tools, technical posts | Comments

PhoneGap and Android have wonderful conversations

PhoneGap is a crazy tool for building “hybrid” smartphone apps. You write HTML, CSS, and JavaScript code for PhoneGap to compile into an app for iOS, Android, Windows Phone, Blackberry, etc. The app will simply use a browser embedded in a native app wrapper (hence, the “hybrid” label).

There are many pros and cons to developing with PhoneGap, but I won’t review those because you can find debates on the usefulness of PhoneGap and others like it so long as you have (at least) mediocre Google Fu. You do have Google Fu, right? Don’t forget that Adobe PhoneGap is oftentimes referred to as Apache Cordova (even in modern documentation).

Anyway, this blog post is meant to disclose the growing pains you could encounter upon trying PhoneGap for the first time for Android development. Although if you’re developing for iOS, you’ll still face annoyances like having to disable WebView bounce (why doesn’t PhoneGap do that for you by default?!).

There were many unspoken hoops I had to jump through to get it working for me when I worked on an outdoor video game app. I really wish someone had warned me about these hoops, but my loss is your gain.

Installfest

I’m sure you were told to just install the Android SDK plus PhoneGap and then you’d be off to the races, right? WRONG. So wrong. Incredibly wrong. Maybe it’s because my personal dev machine is running Ubuntu, but I had to install many missing pieces to the PhoneGap puzzle. Some PhoneGap tutorials cover some of these dev components, but I don’t remember seeing one that covered all of them so here you go:

  • Apache Ant: Java library/tool
  • JRE: Java Runtime Environment
  • JDK: Java Development Kit
  • Android SDK: platform Software Dev Kit (make sure it comes with Eclipse)

After you install the Android SDK, you probably want to make sure you have the right API version. I used API 17 for supporting phones with Android v4.2. Use the SDK manager to install the desired API. Type android in a terminal to open the SDK manager. If that doesn’t work, it’s probably because you have a problem that will be solved by reading the next section of this blog post.

Command Line Goodness

Everyone wants to use command line tools. In fact, PhoneGap wants to use some commands for Android development, but SURPRISE! Those commands are not available until you manually edit your .bash_profile file. You may have to do some searching to find where your .bash_profile sleeps at night, but mine was in my home directory (aka ~/.bash_profile). Keep in mind that it is a hidden file, so you need to enable viewing hidden files (in case you didn’t know). I created a Development folder for my Android dev tools. Then I added the following lines to my .bash_profile (make sure you replace my filepath with your filepath):

.bash_profile
# Adds Android SDK tools to command line
export PATH=$PATH:/home/myUserName/Development/adt-bundle-linux-x86_64-20131030/sdk/tools
export PATH=$PATH:/home/myUserName/Development/adt-bundle-linux-x86_64-20131030/sdk/platform-tools

Now, you’re finally set to begin development with PhoneGap. However, if you want certain features to work, you may have to modify some XML files. Read on, my relative from a common-and-super-old ancestor.

XML File Modifications

Want your app to access external networks? Getting origin errors? Try the sweet taste of the <access origin> tag. Want to enable geolocation? Try the soothing sounds eminating from the <feature> tag. These tags need to be edited/added to the config.xml file of your PhoneGap project. Put your Google Fu to practice if you need more details. Just keep in mind that if you run into various problems in the future, the config.xml file is yet another possible source of irritation to debug.

Here’s a snippet from my config file:

config.xml
# Adds Android SDK tools to command line
<access origin="http://yourserver.com">
<feature name="http://api.phonegap.com/1.0/geolocation" />

By the way, it’s best practice to declare what kind of voodoo your app is utilizing. In case of GPS usage, modify your /platforms/android/AndroidManifest.xml file as follows:

/platforms/android/AndroidManifest.xml
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" />

Down the Rabbit Hole

Using PhoneGap for the first time can be incredibly frustrating. I ran into so many small issues when learning how to use it. There can be problems with connecting a device to your computer, enabling certain phone features, dealing with compatibility quirks, etc.

Connecting an Android Device

Type adb devices into a terminal after you use a USB cable to attach an Android phone to your computer. Make sure that the phone is put into USB Debugging mode. You can find that mode in the developer options. Different versions of Android have different ways to access the developer options.

If you don’t see any devices listed, you may need to investigate drivers for your phone. Sometimes there are other problems with adb that can be solved be restarting: try typing adb kill-server && adb start-server in your terminal (possibly with sudo).

Plugins Not Included

When using GPS, I ran into some blog posts claiming that it’s necessary to install a geolocation plugin. In my experience, it’s not needed, but for other features, it may be a different story. If you’re trying to access a hardware sensor or simply want to use a feature someone has already implemented (e.g., bar code scanner), then you may need to investigate plugins. This might be helpful: About Cordova plugin registry

Android Fragmentation Strikes Again

Be warned: PhoneGap has different bugs for different versions of Android. For example, the PhoneGap app I worked on was built with Android API 17 (aka 4.2 aka Jelly Bean). I tested the app on a phone that uses Android 4.2.2 and a second phone that uses Android 4.4 (aka KitKat). The Jelly Bean phone had no functional issues with the app, but some CSS rules weren’t being applied correctly, which created some off-center layouts. The KitKat phone had no CSS issues, so it looked nice, but it had some functional issues regarding touch gestures. However, that could’ve been a problem with Hammer.js.

FYI, my team also encountered a problem in Android 4.4 and iOS 7 where scrolling wasn’t available for a <section> that had overflowing text. We tried the usual CSS rules, but to no avail.

Links? Links!

I saved a few links that I found particularly useful. I shall deposit said links right here because I can and totally not for SEO purposes.

To PhoneGap or Not to PhoneGap

So is PhoneGap worth the trouble? This blog post probably makes it sound like there’s a lot of shit to scoop before uncovering any treasure. That’s…mostly true. If rapid development is a priority, then PhoneGap is still a solid choice when you lack Objective-C and Java experience. I’ve heard from colleagues that learning Objective-C is its own special kind of hell, so that’s a +1 for PhoneGap, I guess.

To me, tech enthusiasts need to look at the bigger picture: imagine a world where mobile web apps dominate rather than having native apps dominate the smartphone landscape. Firefox OS is actually trying to embrace JavaScript, but why does it matter? Consider the differences in distribution. Forget app marketplaces. Forget Apple acting as a gatekeeper for iOS apps. Imagine that your app is as available as any other website. Web apps are becoming more and more powerful. There are new frameworks (e.g., Famous and another brand new one that I can’t remember at the moment) that make it possible to replicate the oohlala of the much-lauded Yahoo! Weather native app.

The problem is that web apps for mobile devices can’t yet access native notifications. This is a huge obstacle for mobile web app dominance. Companies want their apps to have notifications to enhance user engagement and fight churn. Users want their apps to have notifications because it makes smartphones more helpful (although the line between helpful and spammy seems slimmer than my chances of becoming a guitar master). That said, web apps are getting better at using phones’ GPS sensors, cameras, accelerometers, etc. Hopefully the barrier between native app and mobile web app will continue to whither and eventually die like smallpox. In the words of unoriginal coaches every where, “WE CAN DO IT!”

Questions to Ask Dev Interviewers

- - posted in career development, dev job search, interviews, jobs | Comments

Do you have any questions for me?

When an employer/recruiter asks you this question, you should answer, “YES OF COURSE I DO.” Then you casually bombard them with the questions listed below. Although, you should keep in mind that some questions can be answered just by doing your homework (researching the company). So don’t ask all the questions.

Company Vision

  • Where will the company be in 2 years? (maybe “2 years” should be greater if company is older)
    • Will the business model remain the same? Is the business model still in flux?
    • How many employees will there be in X years? What many of them will be engineers?
  • Does the company plan to scale up? How?
    • Increased marketing efforts?
    • Increased R&D?
    • Growing talent?
    • Creating partnerships?
    • Business model pivot?

Employee logistics/culture

  • What are typical work hours?
  • How often do people actually take vacations?

  • What are some examples of your company’s culture in play?
    • e.g., It’s one thing to say the company promotes diversity, but what are examples of that happening?
  • What aspects of your company help shape the cuture?

  • Older/bigger companies: One of the stereotypical downsides of working at a more established company is that employees don’t feel like they have a big enough impact. How do you ensure employees can make substantive contributions rather than feel like a tiny cog in a big machine?
    • How do you ensure that employees always get to try/learn new things?

Engineering Logistics

  • How many engineers does the company have?
    • How many back-end, how many front-end, how many full-stack?
  • How big are the engineering teams?
    • Will team size change a lot (scaling up)?
  • Do employees ever change teams/roles?
  • Exactly whom would I be working with?
    • What are their roles, backgrounds, etc?
  • How does user feedback ultimately end up reaching the engineers?
  • What kind of development cycle do they use?
    • What is the structure of a typical sprint?
    • How often do engineers deploy?
    • Do they use Agile SCRUM, Kanban, etc?
  • In an average week, how many meetings would I need to attend?

Engineering Culture

  • How does the company ensure quick, painless onboarding?
    • (does the company ensure new hires don’t get overwhelmed by huge, existing codebase?)
    • (or is there no onboarding at all because the company is too tiny?)
  • Does the company have strong opinions on coding aesthetics?
    • Does the company have a style guide?
  • Mentorship?
  • Are there code reviews?
    • Are they scheduled or ad hoc? (“ad hoc” may be BS for “rarely”)
  • Is there time set aside for post-mortems, reflections, retrospectives, etc?
  • What kind of testing is in place?
    • (unit testing, integration testing, e2e testing, QA engineering)?
    • which tools?