A Beautiful Blog

Coda and Transmit Can’t Delete Files

Cory LaViska — Wed, 13 Mar 2013 05:15:41 +0000

I recently came across an issue where Coda and Transmit would just appear to hang when deleting files on my local machine. Fortunately, the good folks at Panic were able to identify the issue. Turns out, it’s a OS X bug.

Here was their response via Twitter:

It’s a bug in Mac OS X. It affects a lot of seemingly unrelated things. We’re hoping Apple fixes it shortly.

The workaround is to run this from the terminal:

sudo killall -KILL appleeventsd

I’m posting it here because I keep having to hunt for it every time the issue comes up, and there are bound to be others that need it. For more details on the bug, check out this post.

Scheduled Tasks Not Running on Media Temple DV 4.0

Cory LaViska — Tue, 26 Feb 2013 08:16:37 +0000

Scheduled tasks (or “cronjobs”) are useful for executing scripts on your server at various intervals of time. They’re fairly easy to setup in Plesk 11, which comes with Media Temple’s Dedicated Virtual (DV) 4.0 systems. However, if you’re using something like curl in your task, it may not appear to work.

Your first thought will probably be, “why isn’t my cronjob running?” So you check the settings and they all look good. You verify the command letter-by-letter, and even paste the URL into a browser to make sure it’s right. And it is. What the…?

Actually, your cronjob probably is running as expected. The problem is that the FTP user doesn’t have permission to run bash commands. Luckily, that’s easy to fix.

Login to Plesk
Select Domains
In the section with your domain, select Manage Hosting
Under Websites & Domains > More, select Web Hosting Access
Change the Access to the Server over SSH dropdown to /bin/bash, as shown here:

That’s it, hit OK and your cronjobs will start running as expected. Just keep in mind that this assumes you’re using the Service Provider view in Plesk. You’ll have to dig around if you’re using another view, but the option shouldn’t be too hard to find.

Sending Emails with Postmark and PHP

Cory LaViska — Wed, 06 Feb 2013 03:07:58 +0000

Sending emails from your app can suck. Half the time, messages that get sent from your own server just get dumped into the recipient’s junk folder. The truth is, successfully delivering emails from your app to your users can be a painstaking task. That’s why we decided to use Postmark for one of our latest projects.

Postmark is an app that makes sending emails from your own app easy. Once you get things setup, your emails are almost guaranteed to hit your users’ inbox. They take care of all the difficult stuff:

We handle things like whitelisting, ISP throttling, reverse DNS, feedback loops, content scanning, and delivery monitoring to ensure your emails get to the inbox.

Once you create an account and get things setup on Postmark’s website, sending an email is a simple call to their API. (Bonus feature: Postmark also handles inbound emails if you need that capability.)

The only problem is that they don’t have a PHP SDK, so they rely on third party libraries to get the job done. Here is our take on writing a minimalistic function to send emails using the Postmark API.

The Code

Before we start, we’ll need to define our Postmark API key. Let’s do that with a constant:

define('POSTMARK_API_KEY', 'YOUR-API-KEY-HERE');

Now for the function. For the sake of simplicity, we’re going to call it send_email. The function accepts an array to determine what to send. A quick glance at the function will show you all the options you can specify, which are mapped to the values found in the documentation. Optionally, you can specify $response and $http_code to get the resulting JSON response and HTTP code that Postmark sends back:

function send_email($email, &$response = null, &$http_code = null) {

    $json = json_encode(array(
        'From' => $email['from'],
        'To' => $email['to'],
        'Cc' => $email['cc'],
        'Bcc' => $email['bcc'],
        'Subject' => $email['subject'],
        'Tag' => $email['tag'],
        'HtmlBody' => $email['html_body'],
        'TextBody' => $email['text_body'],
        'ReplyTo' => $email['reply_to'],
        'Headers' => $email['headers'],
        'Attachments' => $email['attachments']
    ));

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, 'http://api.postmarkapp.com/email');
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'Accept: application/json',
        'Content-Type: application/json',
        'X-Postmark-Server-Token: ' . POSTMARK_API_KEY
    ));
    curl_setopt($ch, CURLOPT_POSTFIELDS, $json);
    $response = json_decode(curl_exec($ch), true);
    $http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    return $http_code === 200;

}

And here’s how we send an email:

$sent = send_email(array(
    'to' => 'you@yourdomain.com',
    'from' => 'Me ',
    'subject' => 'That was easy',
    'text_body' => 'This will be shown to plain-text mail clients',
    'html_body' => 'But this will be shown to HTML mail clients'
), $response, $http_code);

// Did it send successfully?
if( $sent ) {
    echo 'The email was sent!';
} else {
    echo 'The email could not be sent!';
}

// Show the response and HTTP code
echo '';
echo 'The JSON response from Postmark:
';
print_r($response);
echo 'The HTTP code was: ' . $http_code;
echo '
';

Room For Improvement

This function could easily be transformed into a PHP class, and probably should for more serious applications. As-is, you still need to manually handle base64 encoding for file attachments, there’s no programmatic way to use SSL (just change the http to https in the URL), and there’s no timeout for the cURL operation. However, this will get you started using Postmark quickly, so feel free to use it as a starting point in your own app!

Tips for the Aspiring Web Developer

Cory LaViska — Mon, 17 Dec 2012 08:34:10 +0000

So you want to be a web developer…excellent choice! It’s a very rewarding position that can be a lot more fun than most other programming jobs. However, before you take the plunge into a career in web development, there are a few things you should probably consider.

A Different Way of Life

I’m not going to start by telling you that you’ll be working in at least five different programming languages on a daily basis. Nor am I going to talk about the rapidly changing technologies and standards that you’ll need to keep up with. And I’m not even going to mention the multitude of browser quirks that will keep you up into early hours of the morning. All that will come with experience. My goal is to help you understand the type of career—or perhaps the lifestyle—that you’re about to undertake.

As a web developer, the type of organization you work for makes a huge difference in how your career will evolve. Chances are, if you’re seriously considering web development as a career, you’ve already spent some of your own time dabbling in HTML, CSS, JavaScript, and one or more server-side scripting languages. You probably discovered how much fun it can be to make something that millions of people could potentially see. If so, you have passion…and that’s a good thing.

It’s OK to be Passionate

Passion drives creativity. It’s what keeps you working on something for hours on end simply because you want to. It’s what eats away at your nights and weekends. It’s what sucks the spirit out of your social life. If you don’t have that drive, chances are you’re not going to enjoy being a web developer.

In my experience, passionate people tend to have their own way of doing things. The countless hours they spend educating themselves outside the realm of academia gives them insight that people without that dedication will never understand. They change their methods as technology evolves, are generally forward-thinking, and appreciate the “laws” of the web. They take their time to do things right. They care about quality, their user’s experience, and the final product. Employers don’t always like that, but that doesn’t mean it’s a bad thing.

“Right” is Not Always Right

Over the past decade, I’ve had the opportunity to work (as a web developer) for a manufacturing company, an academic institution, numerous web design firms (as a contractor), and for myself. I surround myself as much as possible with individuals who are in the same field as I am. Through many experiences and many discussions, I’ve come to realize that doing the “right” thing is not always what employers want you to do, particularly when budgets and deadlines are involved.

That’s a hard realization to come to when you’re passionate about what you do. Maybe you wanted to spend extra time refactoring that code you wrote—it “works”, but there’s a better way to do it—except the budget doesn’t allow for it. Maybe the client needed it out yesterday and you don’t have time to finish polishing off the interface you’ve been working on. Everyone’s going to know you’re responsible for it, but it’s not perfect yet and people may think your work is substandard. These things can be hard to deal with as a developer, so be prepared to sacrifice the quality of your work—or put in extra time off-the-clock—when budgets and timelines don’t permit.

Never Stop Learning

Where you work also plays a role in how your skills as a web developer evolve. Organizations tend to have their own standards and best practices in place that may or may not be as current as the rest of the world. I’ve seen design firms who are at least 10 years behind in their development methodologies. Their employees aren’t encouraged and, in some cases, aren’t permitted to use modern technologies and techniques. While this is obviously terrible for the organization, it’s also detrimental to the development of its employees.

If you find yourself in this position at any point in your career, you should talk to your management about the policies that are holding your organization back. If they’re too close-minded to consider anything outside their comfort zone, it may be time to find a position elsewhere. When there’s no opportunity to learn new things, you’ll likely get burned out and fall behind new trends in technology. That makes you less attractive to future employers, and overall, it’s really not much fun.

Additionally, it’s OK to make mistakes provided you learn from them. Always, always, always learn from your mistakes. And don’t be afraid to admit when you screw up. You’re human. It will happen. Owning up to things will garner you far more respect and wisdom than placing the blame on someone or something else.

Be Prepared to Give Up Sleep

There have been many, many, many nights where I’ve watched the sun set, then rise, and then set again. It doesn’t happen every day, but it happens. It’s something you have to expect as a developer. Whether it’s your own product launch or a really long workday that got prolonged because a server crashed, it’s going to happen.

Even when I had an eight-to-five job, there were still nights where important things needed to be done. A lot of times that meant working through the night. In fact, many tech positions share this quality, and developers are definitely no exception.

Find a Routine

It’s not always possible, but following a routine as often as you can will reduce stress, anxiety, and fatigue. Eat at the right times and try to get enough sleep. If you get caught up in a day from hell that shatters your daily routine (which you will at some point), do what you can to get back on track.

I can’t stress this point enough.

Put down your phone when it’s bedtime. Wake up when your alarm goes off. If you set aside some time for your significant other or your friends, give yourself that time to recenter. This may seem to contradict some of the points I’ve made previously, but this type of career isn’t just a career—it’s a lifestyle. You have to know how to balance things. Realize your limits and know when to keep going, but also know when to stop.

It’s not as easy as it sounds. In fact, it’s something that I continue to have problems with after many years in the field. However, when I do get back into a routine, I notice a clear difference in my attitude, health, performance, and overall well-being. This is really more of an issue for freelancers and startups, but even the eight-to-fiver can benefit from following a good daily routine.

Exercise Your Mind and Your Body

This is another thing that a lot of web developers who I meet seem to neglect. No matter how many hours you spend doing it, a code marathon isn’t going to make your body healthy. And if your body isn’t healthy, your mind will suffer.

Make it part of your routine. Spend at least 30 minutes a day doing some kind of exercise. Even if you just walk around outside for 30 minutes, it’s better than nothing.

Get in the Zone

Any web developer knows what it’s like, and how frustrating it can be when a distraction takes you out of the zone and blows your developmental buzz. Discover what helps you get in the zone and make it happen. Turn on the right type of music (to me, techno does the trick; anything else and I find myself getting caught up in the lyrics). Turn off your email and only check it at scheduled times. Turn off your cell phone (Android and iOS both have awesome do-not-disturb features). Turn off your instant messager.

Find your zen. Become one with your code. And then watch your productivity rage.

Keep Your Drive

No matter where you work or who you work for, it’s important to keep your drive. A successful developer will put in the extra hours to make an amazing product that impresses his manager and clients. Don’t get discouraged by a missed deadline—rectify it and explain how you needed the extra time to finish it properly…then try harder to be punctual next time. Learn new things as much as possible and integrate them into your projects when applicable. This keeps you up to date with technology and makes you more valuable to potential employers. If your organization fears new technology, stand up for what you believe in and encourage them to evolve their policies and practices.

Just remember, the job you have now is just a stepping stone in the river of your career. Don’t let anyone pull you into the water and drown out your dreams.

Down with the “Share” Widget!

Cory LaViska — Fri, 14 Dec 2012 00:55:05 +0000

In a world dominated by social media, it’s natural to want visitors to share your content with friends and followers. This really isn’t a bad thing, but how you go about encouraging them can actually be discouraging.

The Rise of the “Share” Widget

Six years ago, Twitter wasn’t all over the news. Facebook had just opened itself up to any user over the age of 13. You didn’t see social media logos on television commercials or on every box of cereal at the supermarket. The guy on the radio wasn’t screaming at you to “like” this and that. Those were the good old days.

Today, everyone from the kid next door to the pope has a Twitter account. Major retailers and brands are reaching out to their customers through Facebook, providing them with offers and incentives faster than they ever could before. Companies are tackling customer support by responding within hours or even minutes to angry consumers who voice their opinions to the world. Social media is good stuff, and even our technophobic grandmothers are getting on board.

The point is, everyone knows about social media now. It’s built into our desktops, tablets, and phones. There are a multitude of apps that make posting content to your favorite service a breeze. So why are we still plastering “share” widgets all over our sites?

I was recently speaking with a good friend of mine about this. We both have websites, and we both had those tacky, distracting “share” widgets on them at some point. We were social when social wasn’t cool.

But now, it seems like every site we come across has some kind of obtrusive social-sharing widget included on every single page. Share this, tweet that, blah, blah, blah…it’s just as distracting and tacky as a big ugly banner ad—and people become desensitized by that sort of thing.

It’s Usually Not Worth It

That’s a pretty bold statement, but let’s use the very popular tech blog Mashable as an example. Mashable reaches out to tech nuts—people who use social media on an unhealthy basis. There’s no shortage of social media sharing in Mashable’s audience, so if anyone can pull this off, it would be them.

Considering Mashable boasts 20 million monthly visitors (as well as six million social media followers), you’d think their “share” widgets would have staggering numbers. On the contrary, the average post only appears to get between 500 and 900 collective “shares” in its first 48 hours of existence (an article’s prime exposure period). Here’s an example from an article posted a couple days ago:

While it’s impossible to determine the actual number of visits to each article on Mashable, it quickly becomes obvious that the percentage of visitors who bother sharing them is extremely low.

If a news giant such as Mashable—who garners over 20 million visitors a month—can only pull in a few thousand shares per article, how many do you think your site will be able to pull in?

Encourage Them Without Encouraging Them

So how do you encourage users to share your content without slapping an annoying badge or button on your site? The answer comes down to the most fundamental rule of successful bloggers:

Post awesome stuff that people want to read!

No matter how many “like” or “share” widgets you put on your page, if your content sucks, people aren’t going to pass it along to their friends. But if your content is interesting, people will share it whether or not those widgets even exist.

If you think it’s all about making it easier for users to share your content…think again. Social integration is built right into most devices these days. You can Tweet directly from the Notification Center in OS X. iOS has both Twitter and Facebook integrated right into the operating system. Windows 8 connects with those and many more services through its People App. And all of that goes without mentioning the many, many apps that are available on every platform to do the very same things.

Six years ago, when the average person had no idea what social media was, “share” widgets became a fad. Now, since social media is more than apparent in all our lives, they serve little more than to beg people to do something they would already have done if they really wanted to. Remember, quality is far more important than quantity when it comes to blogging. Besides, wouldn’t you rather have people want to share your content instead of begging them to?

Feature Detection for CSS Transitions via jQuery $.support

Cory LaViska — Sun, 09 Dec 2012 00:41:04 +0000

When working with CSS transitions, the need to detect whether or not the browser supports them may arise. It can be of particular use when working with the transitionend event, which won’t fire in unsupportive browsers.

After finding a number of questionable solutions, I came across this gist that extends jQuery’s $.support nicely.

$.support.transition = (function(){
    var thisBody = document.body || document.documentElement,
        thisStyle = thisBody.style,
        support = thisStyle.transition !== undefined || thisStyle.WebkitTransition !== undefined || thisStyle.MozTransition !== undefined || thisStyle.MsTransition !== undefined || thisStyle.OTransition !== undefined;
    return support;
})();

The value of $.support.transition will be true or false depending on the browser’s capabilities.

Why SaaS is Cheaper Than Installable Software

Cory LaViska — Wed, 14 Mar 2012 03:51:55 +0000

Overview

As a software as a service (SaaS) provider, the question comes up all the time: “Is there an installable version of your software that I can put on my own server?”

In all honesty, I cringe every time I hear this. It’s not that I have a personal vendetta against installable software, it’s because I know what the asker is usually thinking:

I can save money if I only have to pay for it once
It’s safer because it’s on my own server
I can tweak it to do what I need it to do

The truth is, in almost every case, SaaS is a better solution that will save them more time and money than an installable system—they just don’t realize it yet.

I can save money if I only have to pay for it once

It seems like a logical argument at first, but there are hidden costs with installable software that are often neglected. For example, time. Time is money, and as a designer, you probably get paid by the job. This means that one-time costs are very appealing to you when quoting potential work. If it’s free, that’s even better. That’s why so many people use WordPress, right?

In cases like these, you become the systems administrator. That means when something breaks, you’re the one clients are calling to fix it. This may not seem like a big deal if you’re just getting started, but as you grow your business, that becomes a lot of overhead. We have one customer who uses our service to manage over 1,500 websites. Could you imagine having to update 1,500 individual WordPress sites? As you grow, the overhead for each installed system becomes more obvious and the time it takes to maintain them becomes staggering. Since time is money, your cost goes up with each new client you bring on board.

It’s safer because it’s on my own server

Alright, so you’re OK with eating that extra cost. Let’s imagine that you chose to install WordPress to power a client’s new website. You get everything setup, go through a few revision cycles, launch the site, and then you get paid. All is well and everyone is happy.

And then this happens.

You get a frantic call one evening from your client who is panicking that their site has been hacked and they want it fixed immediately. The culprit? Some script kiddie took advantage of a known exploit because someone forgot to update to the latest version of WordPress last week. No problem, you can just restore the site from a recent backup and update WordPress to patch the vulnerability.

Wait…you mean you haven’t been keeping backups?

Now you’re stuck wading through infected pages and database entries trying to repair all the damage. Don’t forget to change all your users’ passwords, the database password, your API keys, and for good measure, your FTP password. Oh, and your client just emailed you saying that Google blacklisted the site for serving badware. And they’re missing the story that they just posted a couple hours ago—and some other articles that were really important. The entire cleanup process can take a long time, especially if the attacker was clever. And this is just one site.

When the dust settles after hours of your time is wasted because of a simple oversight, you then seek compensation from your client for the time you spent restoring their site. Of course, they’re going to be a bit sour that the site you built was hacked and, even though it’s not your fault, they think it is. Your relationship with them gets a bit salty at this point, and they become less likely to recommend your services to others. This can cost you a lot of money, too.

But how much is your time worth? A conservative designer might say $40 an hour. Add those hours up, and I guarantee you’ll find the overall cost of an equivalent SaaS product to be comparatively less—especially if multiple incidents happen throughout the year.

Granted, just about any site can harbor exploits and become a victim, but installable software makes it much easier for attackers to find vulnerabilities since the entire code base is exposed and living on your server. That is a huge advantage of SaaS—it’s much harder to hack what you can’t see.

Another advantage of SaaS is that, if a service discovers a bug or an exploit in their system, it gets fixed automatically. You don’t have to update multiple systems. You don’t have to reset all your passwords. You don’t have to remove malicious code from your site. In fact, since there are many other users, it’s likely that the problem will be noticed and fixed before you ever even realize it was there.

I can tweak it to do what I need it to do

Despite all of that, some folks still think that installable software is better because you can change the code when you need something to work in a way that it’s not intended to work. This is usually a bad idea, especially if you don’t stick to the API.

Why? Because most people that like to tinker with code don’t have a complete understanding of how everything works. Software is complex, and without a solid understanding of the code base, you risk introducing bugs and vulnerabilities that didn’t exist in the original version. It’s also very easy to make changes that hinder the application’s usability.

Aside from that, if you’re not coding off an API, you’ll probably need to make those changes each time an update comes out. If your changes are significant, you will inevitably be reluctant to perform the update which will lead to what I just talked about in the previous section.

Again, this is usually a bad idea.

I can just roll my own service

And then there are the code rogues who would rather spend weeks working on a halfhearted equivalent just to avoid paying a nominal monthly fee, despite the value it would bring to them and their clients.

While I don’t doubt a talented developer’s ability to create an app, it will never be as cost effective as an already-available SaaS product. You might be able to produce a quick-fix system that gets the job done, but it won’t be as maintainable or reusable as it should be, and it won’t be as polished as something that’s been around for awhile. Even if you take the time to turn it into a service that all your clients can use, you’ll be spending more time developing features and fixing bugs than you will finding new clients. You’ll have a new full time job that you don’t even get paid for.

Again, time is money, and while it may seem like an easy thing to do, building and maintaining your own system won’t be as cost efficient as going with an existing SaaS service. It’s just not economical, and it will end up costing much more than what your clients are willing to pay you for.

In the end…

Being in the content management industry, I have the opportunity to interface with established web designers from all over the world. Many of them have tried both installable and SaaS solutions and, while a handful will always prefer the former, the majority who try our service never look back. They would rather spend their time doing what they love instead of being a systems administrator or developing their own applications. The benefits outweigh the cost, and that’s the whole purpose of SaaS.

Ultimately, it’s up to you to decide what tools and services you’d like to use to power your business. Many people find comfort using traditional software applications, but it’s important to consider their disadvantages as well. If there’s a SaaS equivalent that does the job, you might consider taking another look at it for your next project. You might just find that you’ll get more value than what you’re actually paying for.

jQuery Bootstrap-style Dropdowns

Cory LaViska — Thu, 08 Mar 2012 08:37:11 +0000

A really awesome framework called Bootstrap was recently released by a couple of guys at Twitter. You probably already heard of it by now. And you probably already fell in love with it. Today I made a plugin that replicates the features of Bootstrap’s dropdown to better suit my needs.

Backstory

One of my favorite Boostrap plugins is dropdowns, but I had a bit of difficulty getting started with them. The docs say you can apply a dropdown to nearly any element, but they really seem to work best with Bootstrap’s navbar, tab, and pill components. Since I was retrofitting an app that was around long before Bootstrap, this wasn’t going to work for me. That and I was hoping to get a scrollable dropdown (with tips!) and a few other features out of the deal. Thus, this plugin was born.

While the appearance of these dropdowns is almost identical to those of Bootstrap’s, it’s important to note that JavaScript for this plugin was developed entirely from scratch. Some CSS was borrowed, however, especially for generating those gorgeous tips.

Wanna see what they look like? Try it! Wanna contribute to this project? It’s on GitHub

Access Pages Without the PHP Extension Using .htaccess

Cory LaViska — Fri, 03 Feb 2012 02:46:30 +0000

There are a number of ways to make “clean URLs” work on your site, but this one is pretty straight forward. It allows you to access /any-page.php by simply going to /any-page. Just place the following into your .htaccess file (and make sure that mod_rewrite is enabled):

RewriteEngine On
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^([^\.]+)$ $1.php [NC,L]

The nice thing about this is that it doesn’t affect querystrings. With this solution, both of these URLs are effectively the same:

http://example.com/page.php?id=123

http://example.com/page?id=123

Of course, the caveat is that you don’t have “clean querystrings”, but it’s a reasonable trade-off between “clean” and configuration.

Surreal CMS No Longer on UserVoice

Cory LaViska — Wed, 14 Dec 2011 01:43:05 +0000

We would like to inform the Surreal CMS community that as of today, December 13th 2011, we will no longer be accepting feedback through our UserVoice account. This isn’t to say that we don’t want or value your opinions, it just means that we want to hear them from you directly.

For a long time, we’ve been asking for your feedback and directing you to post them on our UserVoice page. In theory, this was a good idea, as it allowed the community to suggest new features and vote on their priority. This gave us a good insight into where you wanted us to take Surreal. However, over time, we’ve come to realize that UserVoice isn’t the solution we were really looking for.

For one, you were thrown into an entirely new interface and required to register a separate username and password. Many users simply stopped at this point, which means that if they didn’t contact us directly we never got the chance to hear their feedback. You shouldn’t be forced to register with another site just to tell us what you think about our service.

We also felt that UserVoice’s interface doesn’t fit well with Surreal’s mantra. Surreal is simple. Providing feedback to us should be just as simple. So from now on, we encourage you to send all your comments, suggestions, and all other feedback directly to us through Surreal’s Help & Support section.

We want to hear from you directly, and we want to take back that personal touch that we lost when we started sending folks elsewhere to tell us how we were doing.