Wednesday, March 17, 2010

Improving Press Releases

A lot of press releases cross my inbox. Some good. Some bad. Some with major errors, some with improper formatting, even some with no mention of the company of origin. Though writing a press release may not seem important to you, or something that you should spend a lot of time on, it's a very effective way to announce what's going on with your company and products.

Based upon what I've seen recently, I've put together a list of how to improve your press releases.

1. Avoid jargon. If you are talking about something really technical it might make sense to explain it because not everyone will know what you are talking about. This is especially important for the members of the press since they might not be well versed in your product.

2. Use full and complete sentences.

3. Don't use abbreviations (i.e. RB or RS instead of REAL Studio). Some people might not be familiar with the abbreviation, so better play it safe and use the full word.

4. Make sure that somewhere in your press release you explain why the reader should care. In other words, what is the significance of your announcement. For example, if you are talking about a new feature don't just list it - elaborate.

5. Don't ask a question and then answer it in the same paragraph or start a sentence with "and." This is a place for more formal writing.

6. Make sure the date on your press release is correct. I've seen some recently that have the wrong year. You want your readers to know your press release is current.

7. Avoid puns and double meanings.

8. Stick to the facts. This is not the time to try to make a joke or tell a personal story.

9. Always remember to have someone proofread your press release. Sometimes you are too close to the draft to catch errors, so it's always best to have someone review it once just for good measure.

10. Avoid using the passive voice, use active voice. For example, don't say "An email was sent by me." Say "I sent an email."

One final recommendation is to not be shy about soliciting reviews. Reach out to bloggers and various media publications, give them free copies of your application and encourage them to write a review. Make sure to add them and anyone you want to write about you to your announcements list so they receive your press release.

If you have any questions about press releases feel free to ask. If you want to have your press release posted to the Announcements section of the REAL Software Forum, send it to me at

Sunday, March 14, 2010

Supporting multiple cores

With today's multi-core CPU's it seems that an application made with REAL Studio running on a single core is somewhat restricting. If you have a lot of data to process, large images to manipulate or other things that could happen in the background, it would seem that with a multi-core machine you could do this faster "if only REAL would make threads preemptive". We get a lot of requests for preemptive threads so that people can take advantage of multiple cores. In fact, this request is number 4 on the Top 20 list in our Feedback system.

It's been suggested that this should be "easy" to do. Just make threads preemptive (so that they will then run on any available core) and voila! Unfortunately, it's not that simple. Let's look at why the current threads are not preemptive. It's hard for you, the developer, to work with preemptive threads. Some languages, like Java, have language features built in to them to try and help make this less work, but it is still hard to get right and very hard to debug when you don't. Much of the framework would need updating to be thread safe and your application's user interface is not thread safe on any platform because the operating systems themselves don't have thread-safe user interface code. If you access something from a pre-emptive thread and that something is not thread-safe, there's a very good chance your application is going to crash. We have had to go to a lot of extra work just to make the threads you have today work without causing problems.

The REALbasic language already has functions like mutex and semaphores that help you make a multi-threaded program. But you have to protect every place you might set a value that could be shared by many threads. This would mean protecting any globals and pretty much anything that is not local to the method or the thread being executed. That's very different than what you have to do today and a lot more work. It's just not "simple" or "easy to use" the way most of REAL Studio is designed to be.

The end goal is to use all cores and thereby make your software more responsive, faster, or able to handle more data, do more things all at the same time. There's been a way to do this for as long as REAL Studio has supported building console applications. The design is to create a main application (GUI or not) and use other helper applications to run separate tasks. The main application and the helpers can communicate in any one of several ways: IPCSockets, TCPSockets, UDPSockets, XML, files, or just about any other way you can dream of. The upside to this way of solving the problem is you can design and implement the main application and the helpers independently and use the debugger to debug each independently. You can use any data in either program in the same way you always have. You don't have to worry about the framework being thread safe as the helper and main application run as completely separate processes with their own memory space. Most importantly, you can do this today.

In fact, some REAL Studio users are using this technique today. John Balestrieri used this technique for a large data processing application. You can read about it here:

and here:

I'm not going to say it's simple.You have to think about what portion of your application can be segmented out into a helper console application. You have to design the communications between the main and helper applications. You have to write, test and debug them. But you don't have to worry about variables changing mysteriously because some other thread changed the value. You don't have to use lots of mutex's or sempahores to block other threads from altering things when you least expect them. And you can use the entire framework that is available to console applications. If you need pictures and graphics that are not available in console applications, you can write faceless GUI applications. Last but not least, you can run as many instances of these helper applications as your computer (or all the computers available to you) can run.

If you think you need preemptive threads today, try the helper application approach and I think you'll be pleasantly surprised at how well it works.

Monday, March 1, 2010

The Compiler: Better, Stronger, Faster

In the 1970's there was a TV show called the Six Million Dollar Man. It was about a test pilot named Steve Austin who crashed in an experimental aircraft and lost an eye, an arm and both legs in the crash. When he wakes up in the hospital he discovers that he's become an test subject for a government experiment to replace body parts with electronic equivalents. But these replacement parts are better, stronger and faster than the biological parts they have replaced. In fact in the opening of the show, the voice-over says that they have made Steve Austin better, stronger and faster.

Like Steve's legs, the compiler is what makes your apps go. And like Steve, we are working on making the compiler better, strong and faster.

While you don't see REAL Studio's compiler or even interact with it much (except when there are errors in your code), it's at the core of REAL Studio. It's what turns your REALbasic code into code your computer can execute. The compiler has two parts: a front end and a back end. The front end parses your code and transforms it into a sort of meta assembly language. Think of this as processor-independent assembly (even though regular assembly is actually highly processor dependent). For each processor type we support there is a different back end to the compiler. The back ends take the meta assembly language from the front end and translates it to the assembly for the processor for which you are building your app. That means PowerPC or x86 today.

We are working on a big change to the back end of our compiler. We are going to be replacing it with an open-source compiler back end called LLVM. It's becoming increasingly popular. If you really want to geek-out, check out We are moving to LLVM because there is a team of people working on LLVM and by switching to it, we get the benefit of their work. For example, it supports all the processors we support or would likely want to support including the ARM processor which is used by most smartphones including the iPhone. Unlike the current REAL Studio compiler, LLVM is an optimizing compiler which means it will make code optimizations that will make your code run faster. How much faster depends on what your code is doing but we have seen speed improvements of up to 10 times faster. LLVM does something called "dead-code stripping" which means that it will strip out the portions of the REAL Studio framework that your application is not using. This will result in smaller applications that use less memory. And for those that deploy on Windows and Linux, LLVM will eventually bring about the return of the single-file executable. And of course the more improvements that are made to LLVM in the future, the more we will benefit.

Today, we are working on getting LLVM supported for RBScript. That is nearly complete. Beta testers have been testing it for several weeks now. Once done, we will then move on to supporting LLVM for the main compiler. Considering how important the compiler is to REAL Studio, you may be wondering what sort of transition will be required to move from a version of REAL Studio that uses our current compiler to a future release that uses LLVM. If you were around for the last major compiler transition, you are probably especially curious. The good news is that because we are changing the back end and not the front end, the transition should be extremely smooth. We expect the vast majority of you to recompile and only notice that yours apps are smaller and faster. There won't be anything new you need to do. That's the beauty of the compiler. It does a lot without requiring much attention.

The move to LLVM is going to be an important step forward for us. And even if you don't use RBScript, you will be able to start experimenting with it via RBScript in the coming months. Eventually, your applications will get better, stronger and faster as well as the REAL Studio IDE since it is created with itself.