Mailchimp and Outlook

When sending out newsletters, it’s pretty typical for the newsletters to render differently in different email clients. Most people who send out newsletters understand these differences and either create PDF newsletters, image-based newsletters or just let the differences go by. But what do you do if your primary stakeholder insists that the email be an HTML email that DOES render the same on all email clients?

The problem that I came upon was that eventually I was able to get the newsletter I was working on to render properly in all browsers except for Outlook on PCs. Mac Outlook 2011 worked fine and had no issues rendering the newsletter. This baffled me quite a bit. I google searched if other people were having the issues and came up with no particularly useful information.

Finally, I found a website on MailChimp that not only tells you how to work around the issues but explains WHY its an issue and I just felt that I needed to share this article and bring it to attention for anyone else who may experience the pain of consistently branded newsletters on all clients and browsers.

http://kb.mailchimp.com/campaigns/previews-and-tests/my-campaign-looks-bad-in-outlook

The golden ticket here that helped me solve the most egregious problems is the fact that Outlook greater than 2003 uses Microsoft Word to render the emails rather than Internet Explorer. Once I discovered that, I was able to open the file in Microsoft Word, save the file as html so that it would output the html that it was rendering and that lead me to the real issue that was causing the problems. After that I was able to resolve the issues within three minutes.

Yay for knowledge bases that are actually helpful!

Iama Speaker at OCWordCamp 2014!

I’m excited to announce that I’ll be a speaker at this year’s WordCamp in Orange County.

Tickets go on sale today at noon and they sell out yesterday. So, I’d get right on that if I were you! 🙂

This year I’ll be speaking on using your theme’s functions.php file versus creating one-off plugins to put your lil’ tweaks and changes in and how to know when its cool to do either one.

Cuz’, “cool” is really the answer here. And by “cool” I mean that it’s appropriate, secure, and you’ll get to sit with the popular kids at the lunch table if you do these things.

See you there!

To Test an Upgrade or Not

I’ve been using WordPress since version 1.5 – that’s 85 versions ago at this point. I also run approximately 20 WordPress installations at any given time. That’s approximately 1700 opportunities to upgrade my sites. I’m no stranger to the yellow bar that denotes an upgrade is available. In fact, I’ve seen it three times this week alone for three different versions, per site.

In the beginning days of the core-update message, it was so convenient and easy to just click ‘update now’ and sit back and let WordPress do it’s ‘thang’ and enjoy the new code after its done.

That was, until somehow something happened and my upgrade didn’t work properly and… in fact, failed so miserably that I lost a lot of my data. I was too flippant about the fact that all of the site’s code is being overwritten with new code and scripts are being ran against my database that I have never bothered to double-check to make sure that they’re going to work on my particular setup.

So, from that point forward, I started to create ‘staging’ versions of each website.  This enables me to take a snapshot of the live server and do whatever I want with it without it ever effecting the real data on the site.

Being a hardcore dev, I prefer to use my own servers for these staged sites, but there are options out there for those who don’t want to manage their own server. Desktop Server is a great solution because you can pull your live server down to your local computer and run the update to test it, and then PUSH the update to your live server without ever having to click the upgrade link on your live server.

You can also use Backup Buddy to move your site from one location to the next and restore your data should something go wrong.

If you are like me and would prefer complete control, you can visit your IT department that controls the production server and ask for a second virtual machine that has identical set-ups and then pull the database and code to the new virtualized server.

If you don’t have an IT Department, you can use WPEngine which has an automatic staging feature built-in.

WordPress has created some documentation that you can follow to set up your staging server. Let me know how that works out!

Regardless of what method you use to create a staging server, I highly recommend that you do that before you consider following the pretty yellow bar down the upgrade path of potential destruction. So, the answer to my question? I say always test an upgrade. But then you probably knew I was going to say that, didn’t you?

And that’s the glass-half-full perspective.

Development Environments, Oh My!

Over the course of my evolution as a developer, there is one consistency that has held true for me and saved me from a LOT of heart-ache. That, my friends, is the Development Environment.

“Pssh, we don’t need no stinkin’ development environment! It’s faster to fix things right on production!”

Okay, I will concede… there are three reasons that are excusable, in my eyes, to develop on the production server.

  1. The problem not reproducible anywhere else, even when you create an exact snapshot of the production server and create an exact copy for a development server.
  2. The datacenter that holds your development environment exploded and there’s no way to make a snapshot to create a new one.
  3. More revenue will be lost than your entire annual salary in the additional six minutes it takes to push fixes through several layers of environments for testing purposes. This is questionable.

So, let’s discuss development environments. Your live site (the site that your main domain is pointed to and that people visit) is an environment usually called a “Production Environment.” Ideally, there should be three or more environments for any given development project: Production, Staging, and Development.

Sometimes these environment are also referred to as a “Server” but the concept of “environment” encompasses more than the server itself (which is the physical computer that your site code is stored that is opened to the Internet for retrieval). The environment refers to the type of software and configurations of the software and the amount of people that are allowed at once to view the code and the way the code is set to store to deliver a page faster, etc. There’s many different factors that create an environment.

A “staging” environment is usually used as a way to test EXACTLY what is on the production website OR EXACTLY what is about to be put on the production website. It is a place that is accessible by a series of users who can confirm or deny any changes that are made and identify issues before they are put on your live website.

A “development” environment, however, is king. Without this environment, I would be six times slower and hit issues with connectivity on a daily basis.  Why? Because a development environment can be set up on a local computer and does not have to be dependent on an internet connection, necessarily. And in my case, rarely.

In some cases, a development environment cannot be set up locally. Usually, these are situations in which the information is protected by laws such as HIPPA or FERPA and the sensitive information should not be put on individual computers that can be stolen and misused. Or perhaps some proprietary software that requires a limited number of “seats.” Who knows, but in those cases, you can usually get a development environment set up remotely, which DOES require an Internet Connection, but should hopefully also require a VPN connection as well.

This post is for Local Development Environment (LDE). There are three levels of LDEs available:

  1. I’m a Doctor! Not an Engineer! Or, in this case, developer. This type of environment comes pre-built with little-to-no need for customization. You just click a button to open the server and start typing in your text editor and BAM. Good as Gold.Example: DesktopServer
  2. I’m the decision-maker here. This type of environment is software that allows for customization of your environment to a limited degree and can be just dangerous enough to screw things up if you’re not sure what goes where.  It’s still one solid piece of software that runs everything, but allows for configurations to be changed or plugins to be added in.Examples: WAMP, MAMP, XAMPP
  3. I’m a total control freak. This type of environment is hand crafted to set up every piece of software required for the environment. This allows for you to make an environment as close to your production environment as possible, but requires advanced knowledge of how the pieces of the environment work and how to not blow things up (digitally, speaking).Examples: Apache, MySQL, PHP, Perl

I tend to use the second type, because I fall between “Ain’t no body got time for that” and deciding things for myself without having to dig into a bunch of hidden configuration files. For my development environment, I use MAMP PRO and tweak the configurations for memory used, number of connections, etc. In addition, I like to pick my own domain names easily, and MAMP PRO allows for this right out of the box.

It should be noted that DesktopServer is for WordPress development ONLY and is built as a layer on top of XAMPP. This is a great solution for people who are purely developing WordPress and use a hosted/managed service such as WPManage because these types of settings are not AS important in these cases.  What this means is that it CAN be customized “under-the-hood” by digging through the XAMPP configuration files, but it’s not required and isn’t built into the application itself.

How has this helped me?

The biggest help it provides for me is the fact that it saves time. When you’re logging into a server to do your work, across an Internet connection, you’re generally dealing with a slight lag or delay. So I’ll sometimes type in my commands and watch them fly by several seconds later while the message is getting sent to the server from my screen. Having this happen on a regular basis is F-R-U-S-T-R-A-T-I-N-G! So the fact that there’s no need to hop across a slow Internet connection is the biggest benefit I gain. Secondly, I also gain the ability to program anywhere I am at. No excuses! Unless my excuse is “I’m off” – in which case, don’t touch your computer, because “off-time” is valuable and important. A third reason way that this has helped me is because I am able to experience bugs and issues and keep those types of issues protected from being viewed by everyone else first (and possibly exploited). It’s always better to release tested and scrubbed code into the wild wild webs as a measure of protection against hackers or other Internet Foe.

One useful tip for setting up a development environment is to use some sort of version control system to move the changes from one environment to the next. I use GIT to track all of my changes and put them on my staging environment. Then you can use a website such as DeployHQ or create a service yourself that deploys all of your changes to your production environment.

Image by deviantArtist 0Atropos0 by way of Google Image Search.

Why Balking At a Past Developer’s Code Makes No Sense

Listen, I’ve been there. I’ve been hired to do a job and I sit down and I open up the developer’s work and my eyes just about pop out of my head when I see how terrible the existing code really is. I have sat there and stared in complete disbelief that a developer could really have done things the way that he or she has done them. I’ve spent time bitching about the past developer to my upper-management and fixing all the hideous issues with the code.

In fact, I think I’ve done this my entire career up until now. I’d wager that many of us do.

When you get hired to do a job at a new company, the chances are pretty high that you’re hired because you have fresh knowledge that will improve the quality of the project that you’re working on. By default, even if you’re replacing a great developer who left on his/her own terms, you will most likely be somewhat more “fresh” and “informed” than the previous developer due to the very nature of taking over code that was completed during a fixed point in history and the fact that you have a different perspective than the previous developer.

I’ve come to an understanding that no matter what project I take over, it makes no sense to question the practices of the previous developer. Here are my reasonings in pretty bullet points (because people like those):

  1. You waste time. All the time you spend skimming the code and balking at how terrible it is, you could be devoting your brain-space to creating solutions to making it better.
  2. You are in the future. No, I don’t mean you’re a time-traveller. I mean that the chances are pretty high that the developer did not know what you know, now. Chances are pretty high that if you were the developer on this project many years ago, you would have probably made some of the same choices. This is because in the past there weren’t so many blogs and coding-sites that share efficient ways to create code for specific reasons. When you were first learning programming, how many times did you write code out the long way before you eventually learned that there’s a shortcut or library for that? In fact, the very nature of you programming for WordPress means that you have some understanding that WordPress is a collection of methods that make programming in PHP easier.
  3. Complaining doesn’t look well on you. When people see you complaining about someone else’s code, despite how it may feel to you, it does not make you look like a superior coder. Instead, it makes you look like a whiner is is essentially saying “I can’t.” You want to be the developer who looks the code square in the code-face and say “I CAN.” Which involves solutions, not complaints.
  4. You will feel better if you take the high road. You will not be devoting your brain-space and adrenaline towards negative experiences. Instead, you can route all of that to being awesome. And that’s really what you’re there for, to be awesome.

So, here’s my suggestions.

Be Proactive. When you see something in code that makes no sense to you, take a note of the issue and, if it’s part of your project, figure out a better way to handle it. If it’s not part of your project and is not a security concern, inform the client that there’s a bit of code that can be re-worked. Explain the problem and offer a solution. Let them know that it’s not part of the project that you’re working on and it would take x amount of time to fix, and you’d be happy to take care of it sooner than later.

Eat some Humble Pie. Put aside some time once or twice a month to go back through your own code-base and check your own work for out-dated practices and code. Get into the practice of looking at your own work you completed in the past and it will give you a better perspective of how code changes over time… and in some cases, several months is all it needs for technology to advance quickly (or before you learn the Awesome Way to Do Things).

Say Something Positive or Nothing At All. If you hear other people dogging devs, either speak up and take up for your fellow brother/sister developer or say nothing at all, but please, do not join in. You can’t possibly know what was going on with that developer that led him or her to make the decisions that he or she did. Speaking honorably about developers will not only give you a warm-fuzzy but it will also win you points with the right people who respect honorable people. Those are the kind of people you want in your life. Well, those are the kind of people *I* want in my life.

Also, gander at this photo, because it can totally be true in some cases. Here’s a slice of pie:

http://xkcd.com/844/
http://xkcd.com/844/

Happy Developing. And congrats on the new gig! 🙂 Or good luck on landing the new gig. Or whatever reason brought you to this blog (maybe it’s because you think I’m awesome and read anything I print, who knows).

HomeStar Evolution Found on:  http://www.animatedheroes.com/homestar

What Developers Want

I’ve been around the Web Development Industry for a decade plus. I’ve met many different types of developers throughout my experiences. Through my observations, I’ve noticed that many people in my industry are in it for the art of creating something.  They seem to love it because they can solve problems and make new things. There’s always an opportunity to learn and try new things. Some people work with clients. Others work alone or with teams. What is common amongst them all is that the end product is important to them. The end product represents the developer’s entire history of work and effort. Of course we want it to be awesome. 

So, in light of that, I thought it might be helpful to share what I think developers want for their clients, teams, or products. Here’s my thoughts:

  • Developers want your project to succeed. That’s partially why lower budgets are harder to work with, because success of the project becomes just a little bit more challenging to deal with.
  • Developers want to solve your problem. Problems are fun little puzzles and we want to figure it out. This is the heart of development in general, finding ways to streamline your business processes. And sales. Besides, what’s more fun than creating solutions? Nothing. That’s what.
  • Developers want to communicate the way YOU need communication. If the email your developer sent is tl;dr (too long; didn’t read), they want to send the information in a format that is readable. Are you a visual learner? Do you need a one-on-one tutorial? Do you need a bulleted list? This kind of thing should be established both up-front and along the way and clients should never be afraid to ask for a different format of communication.
  • Developers also want communication to be TIMELY. If they email you with a question or need feedback, in order for the developer to stay on the timeline that they have committed to, they want to hear back from you so they can continue. If developers don’t hear back, the chances are extremely high that they will have to switch their priority to another project while they wait, and then you’ll have to wait until that’s over, and that just gets messy and complicated… so just hit reply, you know?
  • Developers want to create something new. There’s plenty of libraries and plugins and modules out there, and while we never want to re-invent the wheel, we always DO want to create something that is new, creative, and can give your company the edge you’re looking for. Creativity, coupled with a larger budget, is like a steak dangling in front of a dog. Create. Create! CREATE!
  • Developers want to learn. We are always pushing ourselves to the very edge of technologies and we want to take on projects that will give us more working knowledge an experience in the field of development. If you ask a question and the developer needs time to answer it, understand that this is exciting for him/her because they can learn something new.
  • Developers want to produce something with as little bugs as possible. We all know its not possible to be error-free with technology changing so fast and usage morphing every day, but we want to get there. When we see a bug report, it’s a little bit disappointing. But then it sparks our challenge-seeking side and we dive in and fix it.
  • Developers want to make your day. When we send that reveal link with our “TA-DA” message, this is like giving your best friend the best gift you’ve ever given them. We are so exciting to hear your response because we want you to like the work.
  • Developers want you to feel comfortable with them to give honest feedback in a constructive way.
  • Developers want you to trust that they are an expert in the field. You have all these wonderful brilliant ideas. You have a grandson who took a programming class. You learned html. All that is fine and dandy but your developer most likely reads up on the latest and greatest in the field on a regular basis and can help steer you into a direction that makes sense and does not include scrolling marquees or blinking tags. Developers don’t want blinking tags in their portfolio. That’s just gross.
  • And finally, let’s be real: Developers want your cash. Paying on time is a sure-fire way to continue having a good developer on your team.

Maybe I’m wrong about this. Afterall, there’s always the exception who maybe isn’t in it for the right reasons, and if that’s the case and you continue to employee them, maybe you’re not employing for the right reasons either. I recommend you find a developer who wants all these things and run with that as far as you can go.

tabby's space for thinky thoughts about coding and technology. I like all things homestarrunner.