I know I’m not alone when I say that I absolutely love music. Playing the right songs can totally make my day, and I love trying to find the perfect music for my mood/the weather/any occasion. I love discovering new music and you probably do too, so I’ve decided to start sharing playlists with you!
This one is a fall-related mix. Some of the songs relate more literally than others, but they all feel fall-ish to me. Let me know what you think!
1. Ariel Pink’s Haunted Graffiti — Fright Night (Nevermore)
2. Simon & Garfunkel — Leaves That Are Green
3. The Tea Party — Haze On The Hills
4. The Smiths — Cemetry Gates
5. MGMT — Alien Days
6. The White Stripes — Dead Leaves And The Dirty Ground
7. Stars — Death to Death
8. Fiona Apple — Pale September
9. Tegan and Sara — Walking With A Ghost
10. The Dead Weather — Looking at the Invisible Man
11. Placebo — Summer’s Gone
12. George Harrison — All Things Must Pass
This is a series of posts wherein I share the dev mistakes that I used to make, and hopefully help others in doing so! Also, I reserve the right to publish these either on Tuesdays or Thursdays. As long as the title is cheesy and alliterative, I’m happy.
Back when I was a young developer just learning the ropes, I did some silly things. One of them, as you can probably guess, was developing live (making changes on a live server) instead of locally (on my computer). I was full of excuses:
“But this site barely gets any traffic! If I make a few changes live, who will notice?”
“If I code this site right on a staging server, I don’t have to migrate the site from my computer to the server because it’s already there!”
“Setting up a local server sounds hard and I’m lazy!”
I’ve heard it all, because at some point I’ve said it all. First, let me walk you through the three main ways one can code a site:
Worst: Developing on a live/production site
In my defence, even back in the old days, I didn’t do this too often. After all, it would be ridiculous to develop a full new site from scratch in a public location where everyone could see it. But, not gonna lie, sometimes when I was asked to add new features to an existing site, I found myself being both lazy and overly optimistic and just quickly doing it live on the server.
Overly optimistic? Yep! I was assuming that I wouldn’t make a mistake that would mess up the live site and even potentially ruin my reputation as a developer. And when it’s easy to take out a whole site with a single missing semicolon, this was actually a pretty real risk.
Sub-Worst: Making changes to a WordPress theme using the built-in editor
If you are going to go ahead and make changes to a production WordPress site right on the live server, please never do it in the built-in editor. While HTML and CSS are pretty forgiving, one can royally screw up stuff in PHP (see above about missing semicolons taking out whole sites), and if you make a mistake in the online editor, you risk taking out your entire site with a White Screen Of Death™ and not even knowing why. Usually you’ll only take out the front end of your site, but in some cases, you can even lock yourself out of the admin pages. Know what’s super fun? Trying to restore your website when you can’t even access your website. Don’t do it, kids!
Don’t let this happen to you!
Better: Developing on a staging site
So, you’ve decided instead that you’re going to develop your site on a staging server or a test site that only you and the client have access to. That’s obviously way better than making changes on a production server, because at least it’s private and if you mess something up, the public doesn’t have to know! Yay!
That being said, here’s what I don’t like about this method:
Working off the server means that you’re at your server’s (and your Internet connection’s) mercy. All servers have outages at some point, and because the universe totally hates you, it’ll obviously happen when you need it the most.
FTP is slow, dudes. There’s a lot of waiting and reloading with this method, and I’m impatient.
Your super secret site might not be so super secret. I’ve found other developers’ “secret” “staging” sites in Google before when I wasn’t even looking for them. Oh noes!
Once you’ve given out the secret address for your client to see, they can/will see all the further changes you make, and might see some mistakes that you make (or wonder what happened to the site when it’s taken out by the missing semicolon of doom). When I’m troubleshooting code or trying new features, I’ll often do strange things like outline elements in weird colours, use cats and Samuel L Ipsum as placeholders, and will occasionally console.log(‘some very profane things’). I don’t necessarily need my clients seeing all of that (though, to be honest, I’m pretty shameless about the cats).
Best: Developing locally alongside a staging site
Naturally, my favourite solution is to always develop sites locally (on my computer) so that the only people who can see the site in its incomplete state are me, myself, and I. Then, when I’ve finished, I upload the site to a super secret staging server (which I’ve made sure is hidden from search engines) for the client to see. Any time I have changes to make or bugs to fix, I go back to my local server to make the changes, and then push the changes to the staging site when I’m good and ready. This might sound tedious, but trust me, it’s saved me a lot of grief.
This method is awesome because:
Developing locally is crazy fast! No need to wait for changes to upload or for pages to reload. There are various apps that’ll refresh your browser automatically every time you save a file, and let me assure you, this is a magical experience from which there is no turning back.
I can screw up as much as I want in the comfort of my very own computer. Clients and the public only ever see the site when it’s in good shape. Life is much less embarrassing this way.
Client-facing sites will never succumb to the White Screen of Death™ due to a missing semicolon.
During development, I always have an up-to-date version of the website on my computer in case anything happens to the server.
Coming up next: How I develop locally!
Are you intrigued about the idea of developing locally? If so, stay tuned! My next post in this series will go into detail about how I develop locally, which programs I use, and other fun tips and tricks. And if you disagree with any of this, that’s cool too! Feel free to share your perspective in the comments below or reach out on Twitter.
This month’s wallpaper was both awesome and a headache to pull off.
It was great because I love October (and fall in general), and I’m (not-so) secretly a fan of all things dark, gothic and spooky. On the other hand, it was pretty annoying because of our dear friend iOS 7 and the introduction of parallax wallpapers. Much to my dismay, wallpapers that are the actual resolution of the phone (640 x 1136) are now distorted and artificially zoomed in on iOS 7, which means that all of my past wallpapers look like total garbage on my phone. Boohoo! So, all new wallpapers have to be made with a different resolution to fit properly. Thanks, Apple! Going forward I’ll be including two mobile sizes: one for iOS 7, and one for earlier versions of iOS. And, you know, other phones… but who uses other phones? Juuuuuuust kidding!