Mandi Burley – Page 9 – Today I Learned… in Code

Code School Review: The Magical Marvels of MongoDB gets you started with shell syntax

Code School’s got a new database path! Woohoo!

I was invited by Code School (and comped with a free month subscription) to try out The Magical Marvels of MongoDB. I’m not that experienced with backend data stuff, so I was excited to fill in a bit of my knowledge gap with this intro-level course.

About Code School

As some readers already know, I’m a big fan of CodeSchool.com. Code School is great for both curious newbies (“is coding something I want to do with my life?!”) and for more experienced programmers who want to get a feel for a new technology without going through the hassle of setting up an environment, a new project, and then wading through a pile of documentation.

They’ve grown a lot in just the last year, so check ’em out! Especially if it’s been a while since you last visited.

About the MongoDB course

What you need: a modern web browser – and that’s it. I used Google Chrome and experienced no technical difficulties. All the videos and interactive lessons take place in-browser.

Time spent from start to finish: about 4 hours. The course is divided into 5 sections, with about 10 minutes of video instruction per section.

Topics covered: inserting and finding database documents, transforming record data, filtering documents by various search criteria, embedding vs. referencing, and aggregation.

Overall instruction quality: Excellent. The class’s instructor, Joel Taylor, speaks clearly and concisely. On-screen text is clear and readable, and the graphic design is pleasing and modern.

Wins

The course is largely a tour through the syntax used in MongoDB’s shell. The course does a great job of showing the student how MongoDB structures its data and how to perform simple operations like adding, removing, and updating parts of database objects as well as filtering results by more sophisticated criteria.

The error checking is pretty good – it caught most of my bonehead mistakes and the hints were relative to the mistakes made. Occasionally, I ran into a problem where the error checking couldn’t tell me what I had done wrong, such as omitting the “$” before “$lte” in one case, but I never stayed stuck for long.

I liked how the course never gave me ready-made code to work from. I have a vague memory of an earlier Code School course giving me existing code to add to, and I feel like I got a lot more value out of the repetition of typing the same “boilerplate” (ie: db.wands.find() ) each time I started another section.

The pacing was good: I especially enjoyed the multiple-choice format to section 4, which I felt deepened my understanding of embedding vs. referencing and also was a nice change of scenery from the usual coding challenges. Lessons never dragged on too long, so I could squeeze them in between other things I had going on.

I love the in-lesson shortcuts to the relevant video sections, the reviewable slides, and the suggestion near the end of Lesson 2 to look in Mongo’s own documentation for help with $mul. Since I usually work with documentation up on my second monitor, I appreciate the validation. :P

Shortcomings

As with many CodeSchool courses, the larger context is probably the thing I miss the most in this course. I loved the intro at the beginning: the conceptual rundown (“NoSQL”, collections, the diagrams), but I didn’t get a great feel for the whys of MongoDB. Why would a project be better served by MongoDB over MySQL? What are the advantages of MongoDB and tradeoffs?

The course is a great way to try out the technology, but for me, finding the syntax of a language or technology is usually the simplest step (thanks to documentation). My personal learning curve tends to steepen as a result of the quirks, the gotchas, and the… mindset (for lack of a better word) of a technology.

And, of course, the usual caveat applies: practicing a language or technology in the browser is a lot like reading foreign language words out of a book vs. attempting a conversation with a native speaker. If you were to actually make a project using MongoDB, you’d find there’s quite a bit of setup, interfacing with the rest of your project, and debugging to get through first. CodeSchool doesn’t cover this aspect of the experience, but it’s a pretty big part of using any new technology.

But hey, these aren’t really problems with the course, just things that an intro-level online class can’t be expected to deliver on in the first place. The fact that I’m missing them is probably a testament to Code School’s ability to get me interested enough in the technology to want to know more.

The bottom line?

Great course! I finished it and wanted more. My favorite parts were the sections that went beyond syntax and into best practices, like the embedding vs. referencing parts. Don’t expect to be able to speak fluently about MongoDB after just this one class, it’s too small in scope for that.

But I’m wishing there was more, so – good work, Code School!

7 IntelliJ IDEA tips and settings you’ll probably love

Hardly a week goes by where I don’t learn something new about IntelliJ! Here are just a few of my favorite IntelliJ settings tweaks and workflow tips.

This article was written for IntelliJ IDEA 14 professional and community editions.

1. Exclude some folders from search

If searching in your project is returning a lot of non-project files you’d rather not see (such as files in /node_modules, /tmp, or /build), you can permanently exclude those files.

Go to File > Project Structure > Project Settings > Modules. Right click any folders you don’t want to ever search in and mark them as Excluded. Done!

2. Highlight current file in project hierarchy

Do you want to see where your currently active file is in the project structure? Of course you do. Turn on “Autoscroll from Source” by clicking the little gear in the little toolbar at the top of the project structure window.

Now whatever file you’re editing will be automatically highlighted in the project structure pane.

3. Start a local server with a single click

For all your little web projects that you want to test in browser without bothering to set up a server first, just right click the file you want to serve and choose Open in Browser.

I overlooked this feature in the past because I thought it was just going to open the file all vanilla and stuff, but it totally starts a little standalone server!

4. Resolve git conflicts

IntelliJ IDEA’s git merge conflict resolution tool is fun and convenient. Just right click in any of your project’s files (doesn’t have to be the one with the conflict in it) and go to Git > Resolve Conflicts…

You’ll get a modal with a list of all the files containing conflicts. Choose Merge…

In this screen, you can compare your changes (on the left) to what you got from the server when you pulled (on the right) and view the result (in the middle). Move changes to the result by clicking on the >> and << symbols, and reject changes by clicking the X. You can even edit the final version manually right there in the middle pane.

5. Search EVERYWHERE

You know you’ve seen it… somewhere. But your project is huge and that file could be anywhere. Double-tap the Shift key to open up Search everywhere. I use this shortcut to hop between files all the time because it’s just so convenient.

6. GitHub integration

In the right click menu (click inside a file or on a file in the project hierarchy) there are a couple shortcuts to GitHub. Open on GitHub is handy for jumping right to the file you’re working on to view its history, Create Gist is handy if you like making Gists.

7. Turn on Annotations to know who to blame (it was probably you)

Who wrote this line of code? Now you can know: right click in the left margin (where the line numbers are) and turn on Annotate.

Hovering your cursor over individual lines reveals the last commit message, too.

There you have it: a short ‘n sweet guide to 7 helpful IntelliJ tools, shortcuts, and settings.

Code Fellows Post-Accelerator Update (4 months into first job)

It’s been…

Several years since I first dreamed of writing script or code for a living
1 year since I left my unhappy video game designer job
6 months since I graduated from the Code Fellows Full Stack JavaScript Dev Accelerator
4 months since I started my full-time programmer job

What a trip! Thanks to Code Fellows in Seattle, I am super happy to report that I am now a full-time programmer and loving my new job!

I had tinkered with coding for years in my free time, but never in a substantial enough capacity to turn it into a full time job on my own. Code Fellows was that missing piece, and this is my post-Accelerator update!

My review of the Seattle-based Dev Accelerator can be found here, if you’re curious about the 8 week program itself.

Yes, I got a job after Code Fellows!

And it’s a great job! Like, an unbelievably great job where they pay me to solve interesting Angular and JavaScript problems! My title is Associate Software Development Engineer and I work at Expedia in Bellevue, WA.

So, yes, to all those wondering (and emailing me!), Code Fellows will work you hard, but it is sufficient training for an entry-level programming job (provided you do your part), and the skills you learn in the class will be useful in your job, even if your job is in a different language or technology stack.

Job search rocket fuel: The mid-accelerator resume blast

Code Fellows definitely made good on their promise to put student resumes in front of local employers. Halfway through the Accelerator (4 weeks in), Code Fellows collected and reviewed resumes from every student and fired them off to 40+ Seattle and Eastside employers. Holy wow – they knew about companies I’d have never found on my own.

The “blanket the city” approach worked, but I had a few small gripes that I think other students should be aware of.

The resume blast went to companies I wasn’t interested in (…yet). I gave preference to companies closer to me on the Eastside (so I wouldn’t have to relocate), but my resume went to plenty of companies in downtown Seattle. I felt bad turning down these companies (burning bridges! ahh!), especially since I knew I would become more interested in relocation if my job search started to drag on.
I prefer to customize my resume and cover letter to each position, emphasizing different aspects of my experiences for different positions.
The blast went out too early. My final Accelerator project, my post-Accelerator project, and my portfolio website were not on that early version of my resume. Employers I talked to over the next couple months didn’t know about these things, and those projects and my portfolio site were the strongest showcases of my work.

Basically, I didn’t have iron-clad control over my job search in the first few weeks. And I like iron-clad control over my job searches.

I had only a vague sense of which companies I had already “applied” to and I inadvertently wasted the time of employers I probably wouldn’t have applied to on my own (because they were too far away or didn’t have the kind of workplace culture or benefits I was looking for).

But if that’s my biggest gripe, then I don’t have much to complain about. Code Fellows did a good job supporting its grads, and a quick glance at my fellow classmates’ LinkedIn profiles suggests more than half have already found full time gigs.

Really, I didn’t have to look hard for interesting job opportunities after graduating, and I still don’t – Code Fellows continues to send job leads to alumni, and my LinkedIn profile gets so much email I’m kind of afraid to look in that inbox.

The First Calls

The first couple weeks after my September 26th graduation were really quiet (which was good, the Accelerator was intense and having a little time “off” was beneficial) and then I started getting calls and emails from employers in late October and early November.

Most of these came from “resume blast” employers, but I also ended up in the hands of some recruiters trying to fill really short project positions (like, 3-week or 2-month contract projects). I thought these projects sounded exciting but all of these opportunities fell through for some reason or another.

A big question near the end of the Accelerator that many students asked was whether recruiters were worthwhile. I’ve personally never had a productive relationship with a recruiter in nearly ten years in tech, but someone must be getting value out of recruiters since they’re still in business.

For whatever it’s worth, the three companies I ultimately interviewed with contacted me directly, either via their technical director or their own hiring department, with no recruitment firm involved.

Technical Interviews

By mid-November I had phone interviews scheduled with three companies. Two of them had my info from Code Fellows, and one of them I had applied to on my own. Of those three companies I interviewed with, two chose to conduct the technical interview over the phone.

The first company had a setup where I shared a screen with my interviewer and coded in real-time as my interviewer watched and talked to me over the phone.

The second company conducted the technical interview as a series of questions, sans-computer, although my interviewer had poked through my Github repos and had some questions for me about code I had posted to Github.

The third company (where I now work!) brought me in for a one-hour in-person technical interview, which I really enjoyed and preferred over the phone interviews. This technical interview had the most in common with Code Fellows’s style of interview training, where the interviewer asked me questions and I wrote code on the whiteboard and answered questions as we went along.

In all three technical interviews with three different companies, I felt that my Code Fellows training and in-class interview practice had sufficiently prepared me for the questions I was asked. I was asked questions I didn’t know the answer to in all three interviews, but it wasn’t the end of the world. I just said I didn’t know, said what I would do to find out, then said that I would love to know, and in all cases, my interviewer explained whatever it was to me. (Yay, I learned something new!)

Technical Interviews: Questions I was asked

In no particular order, here are the kinds of questions I remember being asked:

Write a function that determines if a string is a palindrome
What does REST mean? Why is it important?
Write a function that returns just the odd numbers from an array I pass into it
Now modify that function to return every other odd number
Describe dependency injection in Angular
Tell me what kinds of tests you would write for that (whatever that was)

Keeping up after the Accelerator

I filled my post-Accelerator free time building a brand new AngularJS app of my own, a sort of “capstone project” that summarized my knowledge thus far. This project kept my skills fresh and I would recommend other Code Fellows grads do the same (after graduation, of course) to really solidify their understanding of the concepts likely to come up in interviews.

cbm_app_screenshot_11_12_2014 — My post grad project: a recipe site with a back-end interface for adding and editing recipes. I rolled my own CSS and it even has automated tests!

I brought this project with me to my interview on a laptop so I could show it to my interviewer, and that seemed to go over very well. (I got the job, after all!)

Other things I did to stay sharp after the Accelerator:

Codewars “kata” – some of these were really hard but they’re also one of the only training things I’ve found that includes testing
Updated my WordPress blogs’ themes and added customization I always wanted but never really understood how to do before (this stuff was easy after the Accelerator)
Built my coding resume / portfolio site from scratch
Aimed for a minimum of 1 meaningful Github push per day on whatever project of my choosing (I find streaks and those little green cubes very motivational)
Read up on concepts I learned about in the Accelerator but wanted to understand better, like Big O, asynchronous Javascript, data structures

My first month on the job

Like many grads, my primary fear going into my first programming job was that I wasn’t sufficiently qualified. I still felt pretty green, despite all my experience. (Some people tell me this feeling of being inept despite accomplishments that prove otherwise may never fully go away, and recognizing that definitely helped.)

My first week on the job was spent learning the code base, the project structure, learning the workflow (how to run tests, how to get a build running), and setting up my work laptop.

There was so much to learn, and this project is so much more complex than anything I’d coded in before. (This is why I think building real, standalone apps / programs is best for learning to code once you’re past the online tutorial basics.)

Fortunately, everyone was happy to help and answer questions, and I quickly found several more Code Fellows alumni at the company who started before me or on the same day as me. We met up at a local Starbucks early on to share experiences, which was reassuring for everyone involved.

In that first month, my main contribution was adding a button that exposed a back-end feature the rest of the team had been working on for some time. I wrote the logic that determined when that button would be clickable, and added unit and end to end tests to help spot any future regressions.

I also had the opportunity to debug existing Ruby/Cucumber tests, learn a little bit of Scala, and write a few MySQL queries to look at how data was saved in the database. In that first month, I found that the biggest challenge wasn’t writing new code, it was understanding existing code and the complexities of the project’s structure.

The next 3 months

Around weeks 5-6 I started to feel like a more full-fledged, contributing member of the team. The vast majority of my work is in modifying existing code to perform a new function or to fix an unwanted behavior.

Here are just a few of the things I worked on in that time:

Small optimizations to Cucumber test suite aimed at reducing the test code’s reliance on fragile XPaths and removing sleep() and wait() calls
Improvements to the way dates are handled in the app, including adding the much-beloved moment.js library to the project
Collaborating with another programmer to develop a date range “collision” algorithm that can check if a variety of date ranges overlap correctly (or incorrectly) according to a complex set of business rules
Upgrade project’s Angular version and assist in the migration
I had the opportunity to attend a day-long Test Driven Development workshop and bring those practices back to my daily work

My team’s leaders are big fans of pair programming (to the extent that we have dedicated 1pm-4pm “core pairing hours” every day), so a lot of the work I do is in the company of at least one other engineer. I’ve learned so many good techniques and habits from working with my teammates, and I can’t overstate how great this has been for my own development and quick integration with the team.

(I hope it’s apparent from my writing here how very happy I am to be working on this project with this team – I love it, it’s better than I ever dared to hope.)

Happy Ending / New Beginning

So that’s it! I can’t believe it’s been six months already. The Code Fellows Accelerator changed my life: my new role is challenging, and working at Expedia with my team has kept me just as inspired and excited as I was when I embarked on this journey a year ago.

Using tags to run select Cucumber tests

Today I learned… that I can “tag” select Cucumber scenarios and run just the tagged ones, speeding up my testing and making it faster to debug a failing test.

I’m working with Ruby Cucumber tests for my current project and as the tests grew in number and complexity, I found myself wanting a way to run just a specific test.

If your tests are set up anything like mine, you can just add a tag with an @ symbol to your tests like so:

@javascript @tagname
Scenario: Verify that the thing in the thing works
Given I am already logged in
And the page has finished loading
Then the thing should be in the thing

When you run your Cucumber tests from the command line, just add –tag @tagname as an argument:

cucumber --tag @tagname test/specs/features/testfile.feature

This is just a simple implementation that might be useful if you are trying to debug a single test. Taken to its logical conclusion, you could have entire suites organized under different tags for different purposes, environments, etc.

Moving multiple WordPress blogs to one Bluehost account

This post documents the steps of moving multiple subdomain blogs from my old host to Bluehost. I had about 8 blogs to move from Lunarpages to Bluehost, and by the time I was done I had this process down to a science.

These steps are almost certainly applicable to moving from just about any shared host to Bluehost, but they are written specifically to WordPress and to the process of moving WordPress blogs that are using add on domains / subdomains and exist in folders contained within the root (public_html) directory.

If you have a bunch of WordPress blogs on one host, you probably have them set up as subdomains like this:

techblog.mydomain.com
koreanbbqblog.mydomain.com
catpicturesblog.mydomain.com

Most “how to move your WordPress blog” steps assume you’re moving one blog, but this post will help you move lots of blogs. This guide also assumes you were technically savvy enough to get yourself into the situation of having multiple blogs on subdomains and isn’t written for first timers.

Also, this process will take the specific site you are moving down for the some part of the move. My steps minimize the downtime, but be aware that there will be some downtime while you copy your database over to your new host. I was okay with that (it was about 25 minutes of downtime per blog), but if you’re not, you may want to look into alternative methods of moving your blog(s).

If you aren’t already a Bluehost customer and are still shopping for an excellent shared host for your WordPress blogs, personal portfolio site, etc, take a look at their current deals below:

Before you begin

Have all of these things handy:

an ftp program (such as Filezilla)
old host website login credentials (oldhost.com)
old host ftp login credentials (ftp into your site)
new host website login credentials (bluehost.com)
new host login credentials (ftp into your site)
domain registrar login credentials (if separate)
about 1-2 hours to step through this process

Prep Steps

These steps can be done any time. They won’t take your blog down, and the wp-content copy step can take a while, so feel free to start them and continue the “Moving Day” steps later.

Step 0: Log into your existing WordPress installation.

While you’re in here, make sure it’s up to date. Disable any plugins you can live without. Disable caching plugins. (You can keep all plugins enabled, but I find that they move more easily when disabled.)

Step 1: Copy your WordPress blog content to your local hard drive.

Open Filezilla (or whatever) and FTP into your old host. I use Filezilla 3.8, but you should beware of this bug with Filezilla affecting Bluehost users if you’re on 3.10 and reading this in early 2015.

Navigate to your WordPress install folder. It’s probably a sub folder of public_html.

Copy wp-content to your local hard drive. This is where all of your blog’s content is kept, and it’s really the only WordPress thing you need to copy over. Everything else will be handled by a fresh install of WordPress on your new host.

Fun fact about Filezilla: by default, there are speed limits on upload and download. Remove them by going to Transfer > Speed Limit.

Step 2: Copy anything that’s in your subdomain blog’s root folder over to your local hard drive, too.

Did you upload a favicon, a banner, an .html file for identifying your site to Google webmaster tools, etc? You might have things in your site’s root folder, so copy those things over, too.

Step 3: Copy your blog’s sql database to your local hard drive.

Log into your old host’s cPanel.
Find phpMyAdmin and log in.
Find the database associated with your blog (and click it)
Click Export in the toolbar at the top
The default settings are fine
Click OK
You’ll download a .sql file – hang onto this for later

If you have lots of blogs on one host, you might have lots of databases and they may have cryptic names. If this is you, look in the table with the _options suffix to verify which db goes with which blog.

Wait, there’s one more thing!

How large is your .sql file? If your .sql file is under 50mb, skip ahead to “Moving Day”. If it’s larger than 50mb, I have some bad news: Bluehost won’t let you upload it via phpMyAdmin. You’ll have to use .ssh and the command line to upload your database. Those steps are further down in this guide, but they’ll add 1/2 to 2 hours to this process depending on how experienced you are with .ssh and how quickly you can get set up and logged in.

If your database is under 50mb, you can keep following along in the next section.

Moving Day

These steps will take your blog offline while you complete them. Expected downtime is less than an hour, depending on your db size.

Step 4: Change your nameservers to Bluehost’s (or whoever’s).

Log into your registrar (I use and love Dynadot) and find the domain of the blog you are moving. Change its nameservers to the nameservers Bluehost tells you to use for your account.

For me, that’s:

ns1.bluehost.com
ns2.bluehost.com

Step 5: Add the “add on domain” to your Bluehost account

Log into Bluehost, go to cPanel, and look for Add on Domains. Enter your domain into the field and wait for Bluehost to validate it.

After Bluehost validates your domain, scroll down. Keep the “add on domain” radio button checked. Create a new directory for this add on domain. I like to name my add-on directory after the WordPress site it’ll soon hold.

Step 6: Return to cPanel, install WordPress.

Bluehost has (or at least had) a quick “Mojo Marketplace” WordPress installer. I like to reconfigure the defaults and name my site SiteNameBLUEHOST to help me identify its database later on, since Bluehost gives the WordPress databases cryptic names.

Choose your subdomain out of the list (I always pick the one without the .www, might just be personal preference).

Wait for the install to complete.

Step 7: In your FTP program, log into Bluehost and upload wp-content into the new install’s directory.

You just installed WordPress, so navigate to its folder via your FTP program and when you find wp-content, copy your site’s version of wp-content over it. This step may take a while.

Step 8 (small database): Replace that new Wordpress installation’s database with your site’s exported database. (This only works if your database is under 50 mb).

While wp-content copies, you can log into Bluehost’s cPanel again and go to phpMyAdmin.

Find the new database and click it. If you have a lot of databases, look in the table with the _options suffix to identify the correct one. (This is why I like to name my new blog installation something identifiable, especially when dealing with multiple sites. That blog title you entered at installation time will show in _options.)

With the correct database open, click “Check All” and choose With Selected: “Drop”. (Drop is database speak for “delete”).

Now use Import to import your existing .sql file into this database. Note the prefix used. (In my screenshot above, the prefix is wp_ but not all of the databases I imported came with wp_.)

Step 8 (large databases over 50mb): Log into your server via ssh and import your gigantic database using the command line.

If your database is over 50mb, congratulations – you get to use. ssh to upload your database instead because Bluehost’s implementation of php doesn’t let you modify the maximum upload size (BOOO).

Bluehost offers some guides to this process, which (when put in order) are basically:

The import command is really the only tricky part. It needs all of the following:

Your database’s username. This is not your Bluehost account name. The database user is defined when you set up the database and is probably prefaced with your db name. You can see a list of users associated with your databases by clicking on MySQL Databases in Bluehost’s cPanel and scrolling all the way down to where the users are kept.
Target database’s name. This is the database you’re going to overwrite. By default, Bluehost WordPress databases have cryptic names like youraccountname1_wo1234. If you have a lot, make sure you know which one is the one you want to overwrite.
.sql file name. You have this on your hard drive, and you’ll need to upload it to your account into a place you can find easily while you’re in the terminal (you can just dump it into public_html via your ftp program, just remove it when you’re done).

Go back to your FTP program (hopefully wp-content is done copying over by now) and upload your .sql file somewhere on your Bluehost account. I just dumped mine into public_html (you can remove it later). (What was that about .ssh being more secure?)

Now go log in via Terminal (Mac) /Putty (Windows). Remember, you are on your account’s part of Bluehost’s server, not your local hard drive. Use pwd and ls to get your bearings. Navigate (cd foldername) to the folder you uploaded your .sql database file and run the command that imports it.

That command will look something like this:

mysql -p -u username_wo1234 username_wo1234 > yourdb_filename.sql

Uploading through .ssh got the job done, but using it for the first time came with a lot of kinks to work out and added nearly 2 hours to my site’s downtime. Hopefully, the steps detailed above will help you do it faster than I did.

Step 9: Hook up the database by ensuring $table_prefix matches.

If you’re here, congrats – you’re through the hardest parts. There’s a small chance your site is already working.

There’s a larger chance, however, that your site is just a white page or a database connection error message. This step fixes the database connection problem. If you don’t have that problem, skip ahead to the next section.

In Bluehost cPanel, go to File Manager.

Navigate to public_html and click on the directory where you’ve set up your blog. Inside, you should find wp_config.php. Right click the file and choose Code Edit.

Inside, look for $table_prefix on or around line 65. Make sure whatever’s here matches what your db actually uses as a prefix.

If you had a database connection problem, there’s a good chance this solved it.

Step 10: Disable plugins to fix blank white WordPress page

If you’re getting a blank white page, try logging in directly via yourblogurl.com/wp-admin. If you can get in, try disabling plugins until the site loads.

If you can’t get in, go into File Manger and find the plugins folder. Right click it, choose rename, and rename it something else – like pluginsX. Doing this will disable all of your WordPress plugins. Now try yourblogurl.com/wp-admin. If you can get in, reactivate plugins from within your admin panel.

If none of that works, try these steps from Bluehost to try to fix the “white screen of death”.

I found that firewall and security plugins were the most likely to get messed up in the move process and, at worst, had to be reinstalled from scratch.

Step 11: Help, all my blog links are DEAD! 404s everywhere!!

In your new WordPress installation, in the dashboard/admin column down the left side, go to Settings > Permalinks. Note the structure they are currently using.

Select Default (so your links look like http://yourdomain.com/?p=123). Save changes.

Try your links now – do they work? If so, go back to Permalinks and change them back to the way they were. If they don’t work, try editing a post and saving it.

Step 12: Set up email addresses, forwarders for your site.

Chances are, you had some nice emailaddress@yourdomain.com for each of your WordPress sites, probably with forwarders to the main address you use. This step is just a reminder to go to Bluehost’s cPanel and recreate those, along with the forwarders.

Step 13: Move banners, favicons, Google tracking codes, .htaccess, etc back into root folder.

If your sites are like mine, you have a few special things in the root folder of your site. This is a reminder to re-upload those things to your new host.

All done!

At this point, your subdomain blog should now be fully moved over to Bluehost! Well done!

I hope you enjoyed this guide, and if you spotted any errors or outdated information, please let me know in the comments.

And, in case you’re curious, yes, I love Bluehost. I was a Lunarpages customer for 9 years but Bluehost outclasses it in every way – bandwidth, CPU allocation, ability to handle the traffic my blogs collectively pull in, uptime, ease of use, and customer service.

If you’re not already a customer, check ’em out – Bluehost is my favorite shared hosting service for my blogs. (Read more about my blogging-for-profit hobby here).

Note to readers: Tilcode is a participant in Bluehost’s affiliate program.

How to fix “Failed to retrieve directory listing” in FileZilla 3.10 with Bluehost

2018 update: change your connection protocol to SFTP – SSH File Transfer and it should work.

This post is 4+ years old and describes a very old problem yet it continues to draw visitors experiencing this problem (or similar). The method it describes is not secure by modern standards. You should update to the latest Filezilla and use SFTP.

Here’s a dumb thing I lost 2 hours on today: the new FileZilla (version 3.10) uses FTP over TLS by default, but not all hosts support this (like mine).

In my case, I was trying to log into my Bluehost account via FileZilla, which I hadn’t done in a month+ while I was moving and changing ISPs, so that made it even more difficult to narrow down the cause of this error.

Status: Resolving address of ftp.mywebsitename.org
Status: Connecting to 11.222.333.444:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering Passive Mode (11,222,333,444,167,111)
Command: MLSD
Error: Connection timed out
Error: Failed to retrieve directory listing

By far the fastest, easiest fix is to uninstall FileZilla 3.10 and go back to an earlier version. I went back to FileZilla version 3.7.3 and I was finally able to get some work done.

It’s not a great long-term solution, but until hosts support TLS there isn’t much else to do (that I know of – leave a comment if you know better). In the meantime, here’s a Filezilla forum thread on the issue that affected users can follow.

Hope this helps someone!

Simple bash prompt customizations: shortened username, full filepath, current git branch

Today I learned… that your Mac terminal bash prompt can be customized and enhanced well beyond its basic boring default.

A full tour of bash customizations is outside the scope of this post, but I do want to share the simple customizations I use on my own bash prompt.

Screen Shot 2015-02-16 at 9.07.45 AM

My prompt displays my username, the current directory’s file path, and the git branch I’m currently in.

To make your bash prompt do this, open your .bashrc file.

$ open ~/.bashrc

.bashrc is a shell script that bash runs when you open bash. This example modifies PS1 (the user prompt). To make yours look like mine, add this to the bottom of your .bashrc file (the # comments are optional).

https://gist.github.com/manderly/16484e49a2ed26705c22

Save the file, return to your terminal and type source ~/.bashrc to apply the changes.

$ source ~/.bashrc

More bash customizations

That’s just the tip of the iceberg, though, and chances are, there’s more you will want to do to your bash prompt.

Here are two articles I found helpful.

This IBM Developer Works post on customizing bash includes a handy sequence guide and an explanation of how colors work in bash.
Martin Fitzpatrick has a great guide to customizing terminal on Mac that I adapted for my own prompt customizations, plus helpful explanations of how this stuff works.
What is the purpose of .bashrc and how does it work?

How to globally change the font size in IntelliJ IDEA

Today I learned… that you can change the font size in IntelliJ IDEA across all editor tabs and consistently! It’s not a missing feature and you don’t have to rely on the awkward trackpad zoom feature.

Here’s how you do it (on a Mac, anyway).

Go to IntelliJ IDEA —> Preferences —> Editor —> Colors & Fonts —> Font

On the right, look for Scheme name.

Click the Save As… button and give it a unique name.

This step is essential! If you don’t do this step, changes you make to Size further down won’t stick, and IntelliJ won’t tell you why. (The popup is titled “Save Color Scheme” so it’s easy to see why users might overlook its effect on the ability to save font size.)

Now alter the Size setting and you should see the typeface preview change to reflect your input. Press OK and you’re done!

Googling this problem, I found some conflicting answers about how to increase IntelliJ’s font size.

Many IntelliJ users recommend the “trackpad zoom” solution (which you have to enable in Preferences —> General —> Change font size (Zoom) with Command+ Mouse Wheel), but relying on zooming in results in a patchwork of mismatched zoom levels across all your tabs, and you have to manually re-zoom each tab. I wanted a consistently larger font-size across all tabs, with no manual zoom step, and this did the trick!

AngularJS: Chaining multiple functions in one ng-click

Today I learned… a little trick for performing multiple functions in a single ng-click. Just separate them with a semicolon (;) like so:

<button ng-click="selectTab(); $parent.someVar = true">Button Text</button>

This comes with a noticeable caveat: it complicates your template code. Generally, it’s considered good practice to minimize the amount of logic that happens in an html template. If you need to do many things on a single ng-click, you should consider writing (or refactoring) a method in your controller to handle them with just one method call.

Nonetheless, this odd bit of Angular syntax can be useful, even if it never makes it to production. In my case, I needed to modify $parent.someVar on click, which was (at the time) outside of the button’s controller. Ultimately, this code was refactored so that someVar could be modified from within selectTab(), but when I needed a quick and dirty implementation to demo something, chaining functions on a single ng-click got the job done.

Wait, what does $parent.someVar do? What is $parent?

$parent allows code within a child controller to access something contained within the parent scope.

In my project I had multiple scopes.

<div ng-controller="PageCtrl">
   <div ng-controller="SectionCtrl">
      <button ng-click="selectTab()">Button Text</button>
   </div>
</div>

someVar was contained within PageCtrl (the parent scope), but I needed to manipulate it from a button inside SectionCtrl (the child scope). Using $parent, the SectionCtrl code could “look up” into the parent and find someVar. This Stack Overflow Q&A explains $parent with more examples.

Git: How to automatically add the branch name to the end of every commit message

Today I learned… that git can be customized in a number of ways by using its hooks!

On my engineering team, it’s our convention to name feature branches after their corresponding JIRA issues. Likewise, we include the branch (issue) name in every commit message.

$ git commit -m "Fixed the thingy jira/story/ourproject-4555"

Including the branch name / issue name like this means the commit will show up in JIRA linked from the issue itself! Pretty cool. I’ve worked with JIRA a lot over the years, but I’ve never been on a team that actually integrates it with git like this, and the organizational benefits are worth the extra effort.

Alas, it is all too easy to forget to add the branch name at the end of a commit, and I got tired of amending my git messages (which is easy enough: git commit –amend will do it). I knew there had to be a way to automate this.

Adding a git hook

Go into your project’s repo
Open ./git/hooks directory (remember, .git is a hidden directory by default)
Make a copy of .git/hooks/prepare-commit-msg.sample, paste it into the same folder, and remove the .sample extension. You should have a file named simply prepare-commit-msg with no extension.
Paste this into the new file:

# Automatically adds branch name to the end of every commit message.

NAME=$(git branch | grep '*' | sed 's/* //')
echo $(cat "$1") "$NAME" > "$1"

The first line gets the git branch name and sets it to “NAME”.

The second line echoes the contents of your commit message (represented as $1), adds “NAME” to it, and replaces $1 with your message + NAME.

Just save the file and try it out in bash now! No need to reload bash or source anything.

Here’s the gist:

# Automatically adds branch name to the end of every commit message. Handy for git/JIRA integrations.

# Make a copy of .git/hooks/prepare-commit-msg.sample in your repo and name the file prepare-commit-msg (remove "sample" extension)
# Paste the following into the file, save the file, and try it out in bash

NAME=$(git branch | grep '*' | sed 's/* //') 
echo $(cat "$1") "$NAME" > "$1"

More examples

There are many ways to approach this problem, and you can do a lot of sophisticated things with Git hooks. Here are some resources I found helpful in learning about git hooks and git in general:

Append ticket number using git commit hooks? (Stack Overflow)
How to add gits branch name to the commit message? (Stack Overflow)
Git hooks for fun and profit (SitePoint)
Pro Git, a great dead tree reference guide to git (Amazon.com affiliate link)