I’ll be the first to admit it. I’d never touched photoshop before starting this job. I didn’t know anything about design and I certainly didn’t know how to create an image for a mailer.

I may have experienced night sweats in my first few weeks and thought about crying because, spoiled, I’m used to working with Mac products that intuitively know what I want to do and when (why bother thinking when Mac will do it for you)? Famous last words.

Photoshop wanted me to think, plan, and execute. So, I had to prepare. Here’s how I made the Create It With LiveCode mailer campaign.

1. Understand the value. Email marketing is important. I realize anything with the word “email” sounds ancient, but 95% of online consumers have an email account and email marketing returns $44 for every $1 spent. That’s a powerful ROI, so it’s worth asking yourself as you build and grow your business: Do I have a community of people? Am I emailing them? It may be the easiest way to revolutionize your marketing department.

2. Choose a message. Before I can build a mailer, I have to decide what my message will be. The message is the over-arching theme of the mailer and it determines what the image and text reflect. For the Create It With LiveCode campaign, I divided the perks of the Create It With LiveCode course into segments, including the Apple Apps, the Tech and Business Matters Experts, the App Contest (and Prize), and the Skills. Each mailer covered one of these perks as the message.

3. Research. I look for a stock image. We use ThinkStock, but there are lots of good stock photo services out there. With my theme in mind, I find an image that best reflects my main message. Since the course covers Apple’s default apps, I used a lot of Apple App images throughout the mailer campaign to reflect what the course would be teaching and what soon-to-be pros would be learning.

4. Get Busy with Photoshop. Sometimes I simply add text to an image. Other times I have to create an image from scratch, downloading PSDs (Photoshop documents) of IOS apps and placing them over blank phones I pull from ThinkStock. It takes time, but it’s always worth it in the end, especially when I get fancy and create a gif (animated photos moving together as one). I’m starting to develop photoshop skill (and thinking for myself – crazy).

5. Monkey around. Possibly my favorite part of creating a mailer, I put my images into MailChimp once they’re done. MailChimp is the best mass mailing service because it’s fun, easy to use, and you get a high five from the chimp mascot every time you complete a mailer campaign – is there anything better? When it comes to mailers, not really. MailChimp is free, so building your first email campaigns with them is a no-brainer. They also provide sign up forms that you can paste onto your site and use to build your subscriber list. Lastly, MailChimp can schedule mailers in advance, so as I created mailers for the campaign, I could schedule them to go out on the appropriate days.

6. Add Text. My other favorite part. I center my text around my message and my image, highlighting the perks of the Apple Apps, the Business and Tech Matters Experts, or the fact that the course starts soon and the clock is ticking. I always try to keep the text succinct, sharp, and to the point. Because we absorb a lot of content throughout the day and some of us (namely me) have short attention spans, I try to make my content easy to see, understand, and retain in a short amount of time.

7. Add a Subject Line. Every mailer needs a great subject line. Without a strong subject line, the email will be completely ignored and everything else in the mailer (image, text, etc) is a wasted effort. I try to think of something that sounds intriguing – something that I know I would respond to. i.e. “Note to Self” sounds interesting because it leaves the reader wondering, “What? What should I make a note of? Something fun? Something cool? I don’t want to miss out!”

8. Test it. I always send a test mailer (or 10). In a test, it’s important to check that my images link to the right web pages and that the text reads well without any typos. It can be tedious looking at tests over and over, but I do catch things and I’m always relieved I saw them before the public did. To be professional, you have to look professional.

9. Send it. This is when all my hard work pays off. I made a killer image, I wrote savvy text, and the test says everything’s a go – so I can send it. Bye, Mailer!

10. Check the reports. I check the campaign report within 12-24 hours of sending the mailer. The report can tell me how many people opened the mailer and how many people clicked on it. This is a good way for me to determine whether my text, images, and themes are resonating with my community. If no one is opening them, I may need a different kind of subject line. If no one is clicking on it, I can try adjusting my image design. The beauty of it is that I can play with it until I find something that works consistently.

What do you think? Do you have a community? Do you have a subscriber list? Do you send mailers? How can you improve your business with an email marketing campaign?

Did you join the LiveCode Hour of Code? I did. Ok sure I was still on company time, so I was getting paid for it, but let me tell you – I am impressed with how awesome a coder I am.

Awesome coder – too much? I built the messages app and the user interface for the calculator app in 1 hour, that sounds to me like the work of an awesome coder.

Here’s the proof of my success with the Create it with LiveCode Hour of Code. Note – the below is not a screenshot directly from the iphone, it’s actually what I made in 1 hour! Seriously!

Here is the best thing about this demo and the Create it with LiveCode course – Everyone Can Do it. Everyone Can Be An Awesome Coder, Everyone Can Create Apps.

If you didn’t get a chance to catch the demo – it has been recorded and all the materials have been stored on the LiveCode hour of code page.

It’s a short blog post, but trust me, go check out the video, build these apps, get ahead of the game and if you can – get signed up to the Create it with LiveCode Course, it’s gonna be fun.

Happy Holidays Everyone

Steven Crighton

Digital Marketing Manager

Awesome Coder

During the last month I have been switching between translating the IDE to Greek, and refining LC 6.7 and 7.0 releases, in terms of fixing bugs. Some bugs are quite easy to fix. Some others though, can be quite tricky. The first thing to do is locate where the bug comes from, and the next step is to actually fix it. In some cases, tracking down the cause of the bug is not that obvious. However, if you can find a previous version of the code where the bug was not present, then you can use some Git tools to find the specific commit in the history which introduced the bug. You could try to check out each commit, build it, and check if the bug is present or not. Usually there are a large number of commits, so this can take a really long time. This is a linear search. Hopefully, we can do much better by doing a binary search.  This is where the git bisect command comes in.

What is git bisect?

Git bisect is an extremely useful command in the Git version control system. The bisect command does a binary search through your commit history to help you identify which commit introduced an issue. It is quite quick. Imagine that between a working version of the code and a buggy one, there are a few hundreds commits, say N. Using git bisect requires only log(N) steps!

How to use it?

1. You start by specifying two states, a bad and a good one. A state can be a commit hash, a branch name, or a tag name:

In this example, HEAD is the current revision (ie the bad one), and 6.7.0-dp-6 is a tag of a good revision.

2. We then test it for the presence of the bug. We inform Git if the bug is there by running git bisect good, or git bisect bad:

3. Repeating the same process bring us closer to the faulty commit:

4. If we ever arrive at a commit that won’t build for a known or irrelevant reason, or if we just don’t know if the specific revision is good or bad, then we simply run git bisect skip. It doesn’t define it as good or bad, picks a neighbor commit and moves on:

5. Voilà! We fould the commit that introduced the bug!

After finding the problematic commit, we can see the diffs in github, and find out the cause of the bug.

6. We then move back to the HEAD (git bisect reset) and fix the bug!

For some time, I have been wishing that I could have some kind of command-line oriented functionality to LiveCode, beyond writing scripts with LiveCode Server. What if I could pipe things directly to it, or run it as an interactive shell? Being able to very quickly make use of the text handling in LiveCode would be extremely handy for certain command line oriented types of tasks. Alas, this is not possible with LiveCode or LiveCode Server as it currently stands. However, after some thought, I concluded that it should be possible to put together a script to provide this functionality.

Click to Zoom

After some time, I had produced a script which operates as a simple shell type interface. But how does it work? It’s actually fairly simple. The script is a LiveCode Server script, designed to be invoked via command line. When it starts up, it reads in the options passed to it on the command line to determine how it should behave. The options passed to it are in the $x variables, starting at $0. $# tells us how many were passed.

 There are currently two modes: interactive and execute. We can also pass the -p option to tell it to expect data to be piped to it, and read it into a variable called ‘input’. If we pass it the -e option it starts up in execute mode, and expects you to have specified a command for it to run. It then exits after running the command. Usage for this would be like “lcsh -e ‘put hello world’”. Otherwise, it starts up in interactive mode.

Execute mode simply takes the last command line option and uses do on it, then quits. Interactive mode reads 1 line from stdin at a time (i.e. it reads 1 typed line by the user at a time) and then determines what should be done with it. It uses the isCommand function to check the $PATH environment variable (which contains all of the directories which should be looked in for executable programs) to see if what was entered was a utility that is already installed, such as the standard Linux utilities. If it was, it uses shell() to execute the entered command. Otherwise, it uses the do command to execute it as normal LiveCode code, catching any generated errors so that they can be displayed without causing the program to exit:

There is also the optEnabled function that was referenced above. This checks to see if the program was loaded with a specific option enabled:

 This is quite clunky and has many, many problems – for example, there’s no ability to pipe the output of some LiveCode to another program in interactive mode, and you can’t open another program that requires interaction. However, I think that with a lot more work, this could become quite a robust and useful tool. It already provides some very handy functionality in it’s current state, namely that I can pipe to it for text parsing:

Click to Zoom

I will probably keep chipping away at this until I can use it as my primary command line interface. You can get the full code here: http://jasminedavid.on-rev.com/lcsh.txt