There's so much to learn today, and the "to learn" pile just keeps getting bigger and bigger while our time to learn it seems to shrink. So what's a body to do?

Do you ever feel depressed? Professionally that is? Like there is so much to learn and there is no way you're going to be able to squeeze it into your already overloaded day? Yeah, me too, and I am easily depressed to begin with, so it wreaks havoc with my id.

But I can't escape it. The days of being able to secure your job just by knowing RPG are over…as are the days of being able to use RPG III for a decade and a half, sort of frozen in time like one of those big woolly elephants. In today's world, you need to be constantly educating yourself, constantly growing—or else just lucky enough to be in a spot where old technology is king. So, are you feeling lucky?

But what should you learn? CGI, PHP, /Free, SQL, HTML5, CSS3, Ruby, how to successfully date Eurasian supermodels? Let's face it, it's a tough call. And many times the things we read just make it worse because they act like everything is important and everything must be learned and a normal person (like yourself) can really do that. Face it; it's a recipe designed to have you start with that first cucumber martini about 1:30 in the afternoon.

Fortunately, I have it all figured out (actually, I'm still working on the supermodel thing) and want to offer you the fruits of how I have come to terms with the unlimited world of things I should know and the rather limited bandwidth that I have to educate myself. In doing this, I am going to assume that you are already pretty solid on non-ILE fixed-position RPG, CL, DDS, and how to date non-models. Given that, here is what I think you need to do.

Go Modular

The first thing to do is start to design and build modular applications.

This is something that's almost anathema to many RPG programmers. For many years, RPG was not compatible with modular programming, and we have gotten so used to just building one program that it's hard to switch. But do it. As Barbara Morris said at the recent COMMON Virtual Conference, "Modular programming is the norm for many languages," but RPGers lag far behind. More than anything else, the use of modular programming differentiates web-style programmers from their RPG brethren.

And I'm not talking here about using subroutines, although that's a step in the right direction. I'm talking about setting up separate modules for the various parts of your application and then using CALLP and prototyping to access those things.

The argument against this used to be that it was less efficient than a single big program, but with the advances in RPG ILE and faster machine speeds, any supposed inefficiency is dwarfed by the maintenance nightmare of the big program.

But how do you code in a modular fashion? There are a number of options, but the most common one, especially for web applications, is the Model–View–Controller (MVC) design paradigm. The Model corresponds to the business logic. The View is whatever is required to present or display the information. And the Controller handles all of the control activities necessary to bring the various modules into play. It's actually a very simple and elegant option. And it's one that plays right into how to handle web applications where you are using RPG and some web facility.

Sounds trivial, doesn't it? Shouldn't you be doing something in Java? No, not if you have any sense at all. Start by getting your feet wet with modular programming. Train yourself to think MVC, or at least separate modules for separate logical ideas. It will pay off when you start doing web stuff, although learning for its own sake is always good. It looks great on a resume, and models dig that.

RPG ILE and /Free

Of course, if you're going to go modular, that almost requires that you start using ILE. Everyone says they're using ILE, but most people can't tell you what ILE is all about and what the difference is between it and regular RPG IV. (Hint: it's related to whether or not you're using the default activation group.)

True ILE is not that difficult. You need to start using prototyped calls, which involves using CALLP and setting up the parms to be passed in some special D-specs. Once you get used to that, you can create some service programs.

Oh, and while we're at it, are you still using COFFR? Crappy, Old, Fixed-Format RPG? If so, then you need to move up to /Free. I'm just coming off a contract where I spent the first year doing COFFR (because they were on 4.3—OMG, can you believe it?). Then last summer they went to 5.4, and now I'm back where I belong, doing /Free. /Free is very easy to learn, and being able to indent totally makes the code so much more readable. I love it, and if the gods are kind to me I will never have to code in COFFR again (although I will if the money is right).

You can learn /Free in a few days, and if you want to get up to speed, you can check out James Martin's short and very good book Free-Format RPG IV by MC Press or else check out the four tutorials I have on my website.There are also other tutorials out on the web.

It's not just the indenting. I love how keys can be set up for file IO. I love the simplicity. And I'm a big fan of BIFs, which are a huge part of /Free. Do it or die. Well, maybe not die, but you should do it.

Embedded SQL

Let me be blunt. I'm not SQL's biggest fan.

Oh, I know SQL/DDL is truly more powerful than DDS and lets you define some really nifty joins, very complex and all, the kind of thing that eventually ends up on an SQL forum under the heading of "I am doing this and can't figure out why it doesn't work, can you help me?" But honestly, most of the work I have ever done on the IBM i doesn't require that level of power. And DDS and RPG IO are just so simple. Use it if you need it, but switching to DDL/SQL just to be "modern" doesn't seem worth it.

At the same time, being able to do things using embedded SQL is a necessity, especially since it is quite possible that, if you do start to do stuff with the web, you may end up using either MySQL (or some variant) or DDL-based DB2. The bottom line is, for good or ill, you need to add the ability to code SQL to your skill set. You may not use it much, or at all, but you need to be able to do it. Start by being able to do basic Selects and Cursor-Fetch IOs, and then add at least some simple joins. I wouldn't get carried away with some of the super complex stuff unless you end up working in an SQL environment. If you know the basics, you can quickly up your game when you need to.

Web-Based Programming

This is the controversial one. Do you need to be able to code in PHP or some other web language? And the answer for me is…maybe, maybe not.

Web programming is a whole other ball of fur. My preference is to use PHP, but there are other options. Ruby has just been brought over onto the i, and for those who want a more RPG-oriented option, there's RPG Open Access and CGI. Or .Net via the Visual Studio. And, of course, there's always Java. Plus, a number of tools that have been developed by third parties allow you to build the web interface. Of course, in addition to the language itself, you need to have some knowledge of HTML and CSS so that you can build the pages.

If your choice is PHP, then even though you can do procedural type programming in PHP, everybody today is working in PHP OO. And that does require some effort to get into. It's not like the curve for Java, but it's a curve nonetheless. And even though you can do PHP in a simple text editor, almost everyone today is working in some sort of framework, a software tool that helps you develop scripts and provides a structure and standards to what you code. The Zend Framework is one example (as are Symfony2 and Lavarel). No matter which framework you end up using, there will be a bit of a curve for that as well. I'm not trying to turn you off from PHP (it's my pick), but there will be some work involved in getting up to speed.

Or maybe you don't need to really know anything about web programming. Maybe you can just contract that out. It's a valid option. There are a ton of HTML5, CSS, PHP, Java, and Ruby programmers out there, and you may decide that the best approach is to use modular programming to build the M and C modules in RPG and then have the V modules (and maybe some Ms) built for you. It's not copping out; it's bringing in specialized resources to help you out.

But whether you learn web techniques yourself or have it done, you will need to be able to interface it with your RPG programs, and that means using the Zend toolkit to bridge the gap. You can do it without the toolkit, of course, but there's so much in there that makes everything so much easier (not easy, but easier) that you can't pass it up.

The toolkit consists of two pieces; the XMLSERVICE part and the PHP Toolkit part. It's really a collaboration between IBM (they wrote XMLSERVICE) and an open-source group more or less headed up by Alan Seiden, a notorious "smart guy" who knows a ton about PHP and the i and is still surprisingly cool. The toolkit is provided with the Zend Server, but it's not dependent on it, and it will function even if you're not using the Zend Server. Because of that, it can also be downloaded from the Young i Professionals website. The bottom line here is that, even if you farm out the web programming, you'll need to learn how to use the toolkit and how to interface it between your RPG programs and the PHP scripts. It doesn't just happen.

Step by Step…

So, that's it. First, start doing modular design and programming. Second, get up on ILE and /Free so the other kids at school don't beat you up. Third, get a handle on some embedded SQL; you don't need to be an SQL ninja, but you have to know the basics. And fourth…well that's really up to you, isn't it? You'll give your knowledge base a whole other dimension if you learn some HTML, CSS, and PHP (or Ruby or whatever). But it's potentially a long road. Simplest case, get the Zend Server and IBM i Toolkit and work with those while you contract out the real web work. What's important is that you start your journey. Begin today and don't look back. It's too easy to trip and fall on your face doing that.