Free eBook: How to Avoid Economic Ruin

If any of you have an application and are looking for marketing ideas or helpful hints on writing a press release, then this free eBook might come in handy for you. Also, if you know someone who might be interested in or benefit from learning to create their own software, please feel free to pass this eBook on to them.

How to Avoid Economic Ruin: A Survival Guide

Creating Your Own Software

Description: The economy is still in bad shape and there is no promise of things looking up anytime in the near future. So, why not take your finances into your own hand? This eBook will show you how you can supplement your income, or even launch a new career, by starting your very own software company, even if you don't have any programming experience. All you need is an idea and a good development tool to get you started. This free eBook includes the tools you will need to get your new company up and running.

Download here: http://www.realsoftware.com/ebook/AvoidEconomicRuin.pdf

Table of Contents

Chapter 1: The Idea
Determining If There is a Market for your Idea
Chapter 2: Software Made Simple
Choosing a Development Tool
Choosing a Platform
Choosing a Language
Testing Your Application
Naming Your Creation
Spreading the Word
Chapter 3: Creating a Website
Text and Organization
Get Found: Search Engine Optimization
What Not to Do
Creating a Demo Video
Chapter 4: Selling on Your Website
Available E-commerce Tools
Chapter 5: Marketing your Product
Viral Marketing
Facebook
Flickr
Twitter
Free Listings
Public Relations
Press Release Template
Sample Press Release
Paid Search Engine Advertising
YouTube
Blogging
Chapter 6: Conclusion
Appendix A: Resources
About the Author

Linux Personal Free for Open Source Projects

We recently changed the price of REALbasic Personal Edition for Linux to $99, which is the same as the Personal Edition for Mac and Windows. However, if you are developing an open source project, Personal Edition for Linux is still free for you.

To obtain your free Linux key contact Customer Service and provide them with documentation about your project, such as your name on an open source website.

We are making this change because most commercial software that has a free version for Linux is typically free only for open source projects.

Say what you mean

In code it's very important to say exactly what you mean and mean what you say.

Why ?

I just happened to reproduce and fix a bug in the IDE that was the result of code not being explicit about what was intended.

The particular bit of code was in a listbox cellkeydown handler and read

If me.ListIndex <> -1 and key = SpecialChars.EnterChar or key = SpecialChars.ReturnChar then

dim tag as string = me.CellTag(me.Listindex, 0)

But this was throwing an out-of- bounds exception sometimes when you'd press return. But, why?

If you look at the expression you will see that the boolean operators AND has a higher precedence

than OR. This means that

me.ListIndex <> -1 and key = SpecialChars.EnterChar

gets evaluated BEFORE the OR.

This expression turns out to behave as though you wrote

((me.ListIndex <> -1) AND (key = SpecialChars.EnterChar)) or (key = SpecialChars.ReturnChar)

The end result was IF you pressed return the code for the THEN portion WOULD execute when it should not and this caused the out of bounds exception.

What this expression should have said was:

(me.ListIndex <> -1) AND ((key = SpecialChars.EnterChar)) or (key = SpecialChars.ReturnChar))

So the listindex had to be <> -1 before the code in the then would execute.

A very small change, but a very big difference.

Be clear and be safe out there :P

Our 64 bit future

Most desktop computers have used 32 bit processors for a long time now. Among other things, a 32 bit processor limits the amount of memory a computer can access to 4 GB (or to be more precise, 4096 megabytes). The world is moving towards 64 bit processors which can, in theory, address 16 exabytes (16 billion GB!) of memory. Most 64 bit computers don't support that much memory of course but 64 bit computers will certainly allow for a lot more memory than we have today.

For most REALbasic users this change won't require much, if any, work. When we ship a 64 bit native version of REALbasic, integers will be 64 bits rather than 32 bits. That doesn't mean much to most of you. For those of you that are doing bit manipulation and using certain classes, it will most likely mean your code will need to be updated.

Today you have the ability to specify that you want an integer that is 32 bits or 64 bits. Rather than using Integer, you can use Int32 to specify a 32 bit integer. If you are reading and/or writing integers using the MemoryBlock or BinaryStream classes, use the methods provided in those classes to read/write 32 bit integers if you are using the regular Integer methods today.

If you are doing integer bitwise operations or are using integers with binarystreams or memoryblocks, you can update your code today so it will continue to function properly once we provide the ability to compile your project as a 64 bit native application.

64 bit is something we will be addressing to allow your applications to be 64 bit native. I don't have a timeframe to announce just yet. However, those of you that are depending on 32 bit integers (and if you are, you know you are) can update your code now so you won't have any hiccups when compiling 64 bit native applications arrives.

REALbasic Yearbook

What is your "day job"?  Are you a school teacher, engineer, librarian, graphic designer, piano teacher, chef, or something else during the day and also a REALbasic developer at night?  Submit your photograph to the REALbasic yearbook and be displayed on our website!

Send me your picture at pr@realsoftware.com.

View the REALbasic Yearbook Photo Guidelines.

Help Grow the REALbasic Community, Post on The Code Project

Do you have some cool code you want to share?  Post it on The Code Project and share it with the world!  Sharing code with others is both an excellent way to help other developers, but it also helps you become a better programmer.  The Code Project has more than six million members, so by sharing your code you will get a lot of great feedback, bug fixes, free testing and suggestions.  

Submit your article to The Code Project.

Learn more about The Code Project.

You need what language supported ?

Localization.

Something that every developer seems to hope they don't have to deal with.

But I'd say you should want to deal with localization, because if you're localizing your application into many languages then it's also very likely that your application is widely used and hopefully really successful.

REALbasic makes doing most localizing very easy. Just use dynamic string constants and that will take care of the bulk of your needs.

If you plan ahead and use dynamic constants for captions on buttons, strings shown in message dialogs and all the other strings you show in your application you can be ready to localize into any of the languages that REALbasic supports.

But what do you do if after you've created your application you need to localize it into a new language ? And you don't need to do anything else but localize it? You don't need to recompile the application to do this.

You use Lingua.

First you need to export the localizable strings from your application (under File > Export Localizable Values )

Specify what language localization you are creating as the target language.

Import this .rbl file into Lingua and make whatever changes you need using Lingua to add in the new values for this localization.

Then, when all your changes are done, choose "Export to Application" under File > Export.

This will add a new localized file to your application that is set up for the new language.

This works for OS X, Windows and Linux.

That's it. All done.

Note that your application MUST be set up with dynamic constants BEFORE you do this. You cannot change an already compiled application that does not use dynamic constants into one that does by this process.

On OS X there's an alternate way that does not require Lingua and can actually be done by anyone at any time.  You can open the application package and navigate to the Resources directory inside the package. Inside will be any number of directories named with a .lproj extension. There you will see a file called Localizable.strings which holds all the strings that can be localized.

If you need to create a new localization you can use TextEdit on OS X (see the Creating Strings Files Manually section here).  You can duplicate an existing localization (the directory named ending in .lproj) and rename it. The prefix of the directory name is the localization (en.lproj is English, fr.lproj is French, de.lproj is German, and so on)

Once you've created this you have a new localization without recompiling your application.

Good, fast or cheap

There is a saying that you can have something "good, fast or cheap" but you have to pick one. If it's good, you won't get it fast or cheap. If it's cheap, it probably won't be good or fast. You get the idea. That saying is not new and it's not even always correct as it's highly subjective. But it is true more often than not.

As most of you probably know by now, we are working on a new Mac OS X framework for REALbasic. The framework is code that lies beneath your code and translates what you've written in REALbasic into operating system-specific API (Application Programming Interface) calls. For example, in REALbasic you put w = new window1. Behind the scenes we call CreateWindowEX on Windows, gtk_window_new on Linux, and NewWindowReference on Mac OS X.

Our current Mac OS X framework uses the Carbon APIs. These APIs were created to be compatible with Mac OS 9 (Classic Mac OS) as a means to port these apps to Mac OS X. The other set of APIs for Mac OS X is called Cocoa. These were part of NeXTStep which eventually became Mac OS X.

It's become increasingly clear over the years that Apple is focusing its attention on Cocoa. It's understandable that they would want to do this rather than have to update two APIs for each new feature. Several years ago we started a project to create a new Cocoa-based framework for REALbasic. This wouldn't change how you work with REALbasic or how you support Mac OS X (well, not much anyway) but it would provide users with a better experience and allow us to expose new Mac OS X features faster. The project failed. But we are nothing if not tenacious so 15 months ago we started a new Cocoa project with a new approach. Based on our experience developing frameworks for Mac, Windows and Linux, we believed that we would be in beta by Q1 2009 and shipping by the end of Q2 2009. It hasn't worked out that way.

We are making terrific progress. It was slow going at first but we able to move faster now that we have laid the groundwork. At this point, we should be feature complete by the end of the summer and shipping some time this fall. So our schedule has slipped by one quarter. I know many of you were hoping to have Cocoa sooner and I'm sorry to disappoint you. But we would rather do it right than have to do it over again.

So when it comes to good, fast or cheap, we are choosing good.