Web design, development and business.
A terrible, horrible, no good, very bad thing happened to me this month: the Surface Pro that was my exclusive personal and work computer died. Even though I found an inexpensive replacement to order, I couldn't imagine not coding for about a week. I was totally freaking out.
After a few unsatisfying days of merely reading about web development topics, I set to work on figuring out how I could get some real work done, armed only with my iPhone.
Not wanting to hunt down a new solution if it was unnecessary, I first turned to tools I've used before:
Codepen wasn't terrible in a pinch. However, the layout and on-screen keyboard really wasn't optimized for coding on a phone. Making minor changes took a lot of time, and it was easy to end up with really buggy code.
Cloud9 had the same problems but with an already more cluttered interface. It explicitly doesn't support mobile browsers and it has been made clear multiple times that making Cloud9 mobile-friendly or developing a native mobile app for it is not anywhere on the roadmap.
When exploring the Cloud9 issue, I saw mention of an alternative cross-platform cloud IDE called CodeAnywhere. However, the iOS app appeared to have not been updated since 2014 and after four unsuccessful attempts to so much as create an account and login, I figured there had to be something better.
After some frustrating experiences, I came across tools and techniques that worked beyond my expectations, allowing me to code productively with just a phone and that can allow you to do it, too.
Buffer Editor was a hidden gem in the App Store. It didn't have a presence from advertising or word of mouth or even enough reviews to warrant a rating. It would be easy to underestimate Buffer.
When actually downloaded, though, it's clear that Buffer Editor is a real, powerful editor truly optimized for a mobile experience. Features that won me over included:
It also included useful features that I didn't utilize such as Vim support and support for bluetooth keyboards.
While it isn't free, the 4.99 USD price I got it for was well worth it, especially compared to the popular Coda at almost 25 USD.
Being confined to a phone gave me the push I needed to start building more websites and applications directly in a VPS solution like Digital Ocean rather than starting out solely on a local machine. Using a Virtual Private Server (Digital Ocean calls them droplets) allows setting up a development environment and managing files/servers without needing a local environment to work with, since it's on another computer in the cloud. Another benefit of VPS is that from the start, a project isn't tied down to one local machine, even if it hasn't been checked in to version control yet.
Digital Ocean has proven to be easy to use (and inexpensive), and there is a wealth of documentation and guides for folks new to running servers.
Accessing the droplet remotely was easy in Buffer Editor, simply involving adding a new SSH connection and filling out the relevant settings with information from the droplet.
The wonderful and problematic thing about web development is, of course, the primary thing you need is a browser. Using a VPS to develop, you have access to a terminal console, but not a Graphical User Interface or a traditional web browser.
When developing a web app, you often need to be able to start a local server and access
localhost in the web browser, since that's where the development server displays the app. Unfortunately
localhost means this computer, and so it's inaccessible outside of the VPS hosting the app files.
The workaround here involved learning more about servers and requests:
When starting a server, it sends what is called a bind request to indicate that it is ready to receive requests associated with an IP address. Local servers typically bind to
127.0.0.1 because that IP address is used to loop back to the requesting computer; each computer can only request
127.0.0.1 from itself, which is usually convenient for developing.
That's clearly not an option. You need to have the server bind request indicate its publicly accessible IP address instead so that it's accessible from a browser outside of that computer. This IP address is easily obtained from Digital Ocean, and the workaround involved adding a
--binding flag like this, for starting a Rails server:
Now, instead of typing
localhost:3000 into the browser's address bar to view the app, you would type the publicly accessible IP address, like
XX.XX.XX.XX:3000. As long as the local server is running with the binding flag, the app will be accessible remotely from the server's IP address.
Buffer Editor is especially convenient by keeping the server running after you back out of the terminal (so you can open it again and continue to develop). This can be confusing at first, but to stop the server, lock and unlock your phone.
From here, you can utilize git like usual, get to work and debug your code wherever you are and regardless of WiFi/Ethernet availability. In fact, the day before my new computer arrived, I was able to make 6 commits and push them to GitHub, all from my iPhone.
While my day to day coding will be on a traditional desktop or laptop when it's available (since two hands are faster than one), I continue to utilize these tools to work on my projects when I can't bring my laptop somewhere or when mobile internet is all I'll have access to, such as riding in a car.
I'm actually thankful for the experience of losing access to the computer, because it forced me to find a solution that now allows me to code virtually anywhere.
Motherhood is a nonstop guilt trip, and few things cut as deep as not seeming to spend enough time with your kids. Combine that with the time-consuming nature of coding, debugging, and research, and you have a recipe for a stressed-out mom.
What’s a mom to do? Here are some ways I keep my own kids engaged while I work at home.
I don’t know about your kids, but my four-year-old absolutely loves puzzles. So when I’m working on code, I break out a tablet for him to play ScratchJr.
Scratch and ScratchJr are free programs created by MIT that allow children and newcomers to code to write logic using puzzle pieces. Kids and adults alike can utilize things like loops, conditional statements, and functions to create a vast variety of programs and games. The individual puzzle pieces only fit where the logic makes sense from a coding standpoint.
Scratch can be played with in a web browser, or you can download the software to use it offline. ScratchJr is designed for tablets and works on iPad, Android, and Kindle Fire. Each one organizes pieces into various color coded categories to make it easier for kids to pick it up quickly. And the best part for a kid learning to code: no semicolons!
Since the Jr version doesn’t require reading comprehension, my son likes it for controlling the avatars and making his own mini games. And he loves feeling like he’s doing his “work” while Mommy’s doing hers.
Almost everyone who builds products for some user to eventually, well, use knows that they’re not always all that good at figuring out how they’re supposed to do it. Even by having others try out your site or software, it’s almost impossible to know how your genuine users may try to do things differently.
One way to at least check that a user’s wrong clicks won’t break your site or program is to simply click around randomly and see what happens. Do you know who are really good at randomly clicking things?
Kids, of course. Let them tool around with your front end and watch from behind them to see if anything breaks. My sons are always trying to snag my laptop so they can press as many keys as they can, so giving them the opportunity to click and tap away with no consequences is a really special treat.
When kids are going to be underfoot, it helps to get them completely absorbed in what they’re doing so they’re less likely to try to wander off. This makes Legos and other building toys great choices for when Mommy needs to get work done at home. Once they start constructing something, it usually hold my kids’ concentration for an extended period of time.
Plus, not only do they have something to focus on for a while, but as long as they get a chance to show me their finished projects and get my smile of approval, they’re as proud and happy as if I had been beside them the whole time. Keeping a camera (or camera phone) by the computer also helps, because then I can take a picture of whatever they’ve built when they present it to me; kids tend to love when their creations are special enough that Mommy wants to take a picture of them.
Doing some whiteboarding or wireframing or need to create some flowcharts to get the hang of your algorithm? Young kids often don’t realize exactly what Mommy’s doing when she starts drawing out what she’s working on, but it can definitely inspire them to draw their own little masterpieces.
When I break out my drawing tools, I also take out some crayons for my sons. They get to draw anything they can think of while Mommy puts some flowcharts together. Most importantly, they feel like they’re doing something just like Mommy, so they don’t feel left out when I’m working.
Of course, not all of code work is active. A lot of time is spent reading books and documentation and doing research. As soon as I appear not to be doing anything, my kids decide that I need them to spice things up a bit.
How do I keep them still? When I do my reading, I try to sit my boys down to do their reading.
My oldest is starting to read words and my youngest likes to look at pictures, so if I give them a good stack of books based on their interests, I can usually get them to enjoy the quiet time long enough for me to make progress.
None of this is to dismiss the fact that working at home while simultaneously taking care of kids is hard work. These options help to make it possible, but I still stay up several hours after my kids go to bed so that I can concentrate for a bit.
Let me know on in the comments if these helped you or what you’ve tried, or even work from home horror stories.
When learning to code, you’re often your own worst enemy. Speedy learning slows to a crawl and you start to wonder if you were cut out to code at all or if you were really an imposter all along. One good way to avoid this self-defeating spiral is to surround yourself with fellow coders as often as you can manage.
Of course, there’s no limit to the support you can find online, but there may be times when you really need a person there with you sharing their own struggles, helping you on bug hunting excursions, or to contribute to a project with you. If you don’t happen to live right near an existing code group, however, don’t despair. We’re makers; you can make your own!
Now, I’m sure someone out there is probably saying, “Gee, Chazona, I’m sure forming a group is easy in a big city, but there’s no way I can find interested people in my [insert suburb or town here].” And unless that person is in extremely remote conditions, they’re probably selling their area short. My advice is not to assume lack of interest before you actually try it because you’ll probably surprise yourself.
So what I’m going to do is share with you how I went about forming a local group when I moved to a village outside of Richmond, VA, and some of the things I learned along the way. While everything may not apply to every situation or location around the world, it should give you an idea of where to start if you’re feeling a little lost.
I’m not going to claim that I came up with the idea to create a local group all on my own. As a student of Free Code Camp, one thing that was consistently recommended throughout the program was to code socially: seek out local groups, pair program, contribute to group projects. Around the same time, my family was in the process of moving from our Richmond suburb to a slightly more distant village. The nearest local coding groups were more than 30 minutes away and met late in the evening, which for a full-time parent without childcare was just not accessible. What was I going to do?
Well, Free Code Camp also had a listing of existing Free Code Camp unofficial groups and recommended that those who didn’t have a group within 15 - 20 minutes of their home just create their own. The recommended medium was Facebook Groups, largely because it’s free to use and an incredible number of people are already using Facebook for other things. So I went on Facebook, followed the Free Code Camp guide and set one up in a matter of minutes.
Once the Facebook group was up, it stagnated a bit, growing by one or two people at a lethargic pace. As a natural introvert, I was not well-suited to heavily marketing my group, and the tools available through Facebook were not always helpful. While I had only expected a handful of people to eventually show interest in the group, I was starting to wonder if there was no interest in code where I lived.
But I wasn’t ready to give up yet. Instead, I took a look at Meetup, a web app I had considered when I’d first moved to the Richmond area but had never gotten around to joining an area group. It seemed simple enough to set a group up, so I filled out the information up to the last screen, expanding the group to be called Midlothian Code and include coders learning a wider variety of languages. I stopped short of purchasing the organizer subscription, and you’d do well to do the same if you utilize Meetup: within 24 hours of abandoning my cart, I got an email offering 50% off my first payment, which I used to pre-pay for six months for $30.
The thing Meetup did for my local group was to bring in interested people. Three days after I formed the group on Meetup, they announced the group to users who had already indicated interest in things like web development and programming, and Midlothian Code grew to almost 30 members overnight.
Suddenly I was in the position of needing to get meetings and events up and running, and of course, I had no idea what I was doing.
I started offering Coffee and Code meetings, since that was the common start for Free Code Camp-based groups. Ultimately, these ended up initially being half general meetings and half chit-chat on development topics. We wanted to start working on projects right away, and I wanted to be able to offer more interesting meeting content. I set up a set of chat rooms on Gitter and an organization account on GitHub to store code. Meanwhile, Meetup was proving not to be as useful for group communication as it was for advertising. I was not getting prompt notifications of messages and comments, the mailing list was outdated and a challenge to use properly, and it was difficult for members to know when information was posted to the message board. Change was needed again.
As we found Meetup slowing down our group’s growth, I started looking into communication tools. We would ultimately need a website, but I didn’t seek to put one together in case our web developer members wanted to contribute to the original site. So while I registered a domain name for Midlothian Code on Google Domains, it was mainly so we could add Google’s G Suite tools to have a professional email and suite of office tools.
Instead of building out our website early on, we went with Mobilize.io, which allows for participating in discussion topics, RSVPing for events, and answering polls right from email. I could filter members by things like languages they were interested in and skills they currently had to ensure what we did better fit them.
Meanwhile, I utilized Tailor Brands to obtain an affordable logo for about $20 and some graphic design materials. Between my own code study, organizing the group, and taking care of my kids, I was having to get a little less DIY with my local group than I would have liked.
I also applied for room reservation privileges at my local library, which made our venue situation more secure. Libraries are often a neglected resource, but you should definitely take a look at what your library network offers if you’re starting a local group as it provides vital free services you’re unlikely to get anywhere else.
And yet, now we found our membership split with some still exclusively on Facebook, most exclusively on Meetup, and a few using the Mobilize site. It was difficult to coordinate members, to ensure information was up to date on all channels, and even to have an idea of how many of our more than 70 members were actually active. On top of this, as Midlothian Code was expanding, it was going to rapidly break the limits of Mobilize’s free plan and get too expensive to sustain.
It was becoming increasingly clear that getting some kind of coherent, functional website up for the group was going to need to take precedence over the pride of hand coding the site as a group. We needed one centralized place where the most up-to-date information and copies of any shared resources could be found. As much as I had tried to avoid it up until this point, it was time to look at Wordpress.org.
I had already reserved a domain name for Midlothian Code, but Google Domains did not provide hosting, SSL certificates or any of the other services you might look for in a DNS provider. Instead, I sought out an inexpensive hosting provider to transfer the DNS service to. Choosing a web host is a big decision, but because our group is still a bit on the smaller side and not for profit, I sought out the least expensive provider that offered month-to-month payments. Do not go the route I did as I ended up using 1&1 Hosting, which is a terrible provider with basically no customer service. I actually set up hosting with a new company and migrated my site over in the length of time I spent on their customer service phone line waiting for a human being. I can comfortably recommend WP Engine for managed WordPress hosting and Digital Ocean for nearly everything else, otherwise, you’ll need to do some research. Make sure you can find quality documentation for your prospective host and more than one point of contact for service.
From there, I pieced together a site that would benefit Midlothian Code while we grow. I’m currently in the process of ensuring its features meet our needs, and once it is done, we will start scheduling and hosting coding workshops. I can’t wait to see how the group grows from here.
If I had to do things all over again, I would have started with Meetup and creating a group website from the beginning, and I would give no hesitation to using self-hosted WordPress for my group’s site. I would take the time to find a better host, though.
The attention that Meetup gives groups is valuable, although I would limit our use of it to a length of time that brings in new members since it doesn’t provide a satisfactory return on investment after that.
Building a site, meanwhile, is possible almost for free while the group is still small (I’m only paying for domain, inexpensive hosting, and email). The benefit of having one primary place to direct members and have them congregate can’t be overstated. Once members can be organized, that’s when they can really get to work on coded-from-scratch projects that can be highlighted on our site.
Are you thinking about starting a local coding group where you live? Share your concerns in the comments!
I keep having to remind myself that I’ve only actually been studying on Free Code Camp for ten days, in between taking care of kids and other daily necessities.
Sometimes, it’s to ensure I don’t get lured into a sense of hubris. I’ll be flying through tutorials, devouring them as though they were wrapped in bacon.
I’m still fully committed to the path Free Code Camp lays out to full-stack proficiency, and I am dedicated to completing it within one year, despite the challenges of finding time with two small children running around. As someone who has been interested in learning code for quite some time but — seeing the explosion of languages being sought — had no idea where to start, I this is the single most useful individual tool I’ve come across.
But I’m realizing that while learning by doing is critical to retaining and being able to use the knowledge, it won’t all come from one place. I went through and started evaluating what additional resources would be helpful for my learning path:
In addition to more specific resources, I am also taking advantage of practice that may come from day to day activities, like my blogging. Today, I needed to reconfigure my blog’s Twitter cards to enable photos and get the site whitelisted. It was frustrating, but I learned a great deal about Twitter’s integration, and I managed to create cards that should help drive engagement and conversation.
Of course, different forms of challenge and competition can keep things interesting, so finally I set up an account on HackerRank so I can progress through additional algorithms and participate in contests to show how my skills grow.
Needless to say, I’m not nearly ready for even the “Newbie” contests — if you want to feel better about your own progress, I’ll be happy to tell you how I scored. Eventually, I’ll get there, and in the meantime, the challenges and algorithms are helpful in gaining some of the academic knowledge I’m missing out on by not having a computer science degree.
And of course, lastly, I’m going to need to get more involved with other coders: share, comment, and interact as part of a community. Conveniently, Free Code Camp recommends local meetup groups for Coffee and Code and other types of events. The nearest one to me is in a neighboring city 30 minutes away, which is a barrier to attending; FCC recommends having the groups as local as possible, so setting one up for my town will probably be on the docket for tomorrow or the next day. And that’ll provide a great opportunity for some leadership experience.
Have you hit a wall (or many) yet in your coding adventures? How are you adapting to move forward? Feel free to share in the comments!
These two words have been typed countless times as developers take their first steps in new languages. So they should be fitting now, as I begin to chronicle my own path from fledgling coder to full-stack developer. This is the start of what is proving to be a fascinating, if vexing, journey.
To begin, I should probably take a moment to share how this blog came to be, particularly since it almost didn’t happen. Given the value and necessity of GitHub, I chose to host my page using their GitHub Pages tool. Of course, as it seems everyone new to code finds out on discovering GitHub’s utility, there is a steep learning curve to the tools. I ultimately created and deleted the site twice, staying up until 2 AM to set it up, so I hope that my experience makes it easier for someone else.
For my setup, I chose to use Hubpress to manage my blog. Other options are available, but they typically require pushing content using the command line, while Hubpress uses a dashboard interface. If you choose to go this same route, the most imporant thing is to fork (copy) the Hubpress repository to your GitHub account.
Do not create your GitHub page first. Once the repository is forked, you can rename it in the style
.github.io that GitHub Pages would have used. You need to retain the fork relationship with Hubpress.io to ensure you can apply updates later on, which won’t happen if you push everything to an empty repository.
If you intend to use a custom domain, this is a good time to ensure it is ready to use. I used Google Domains for my blog. Google Domains is in Beta right now, but my experience with it has been smooth so far. Most domains are available for $12 a year with free private listing and easy integration of services like Apps for Work.
From there, you can go into the Code section of your repository, under
/hubpress/config.json. You should fill in as follows and merge the changes in your local master branch:
Go back into settings and scroll down to enter your custom domain in the applicable field. Click save.
Back in the root of your repository, enter the file
CNAME and make sure your domain is listed on two lines, as follows:
Once this is all complete on the GitHub side, you can sync up your domain. If you used Google Domains, this part is manageable.
My domains, click
DNS and scroll all the way to the bottom. For your site to work with or without the
www subdomain, you should include a
CNAME entry with the
www subdomain and your
Do not use a * or wildcard subdomain to set up your GitHub blog. This will allow anyone to create their own page under your primary domain.
You also need two A records pointing to GitHub’s IPs. At this time, they are
These IPs can change over time. Confirm the current ones at GitHub Apex Domain Help before pointing your domain to them.
From there, it may take a few moments or up to 24 hours for everything to point where it should. When you view your site, if you see the following screen, you have set everything up correctly.
/hubpress to the end of your domain to access the dashboard login screen, and use your GitHub username and password. From there, you will see a blank page — your posts screen — and a menu bar you can use to access settings like your blog’s title and social media links.
You must set your blog’s title before you start trying to save posts.
Congratulate yourself on a job well done, as this process trips many people up. Once you’re ready to write, pull up your favorite editor like Notepad++, brush up on AsciiDoc’s plain text syntax and you’re on your way.
How was your first experience jumping into GitHub? Share your experiences in the comments!