|What Web 2.0 Development Skills Should an i Programmer Have?|
|Programming - Web Languages|
|Written by David Shirey|
|Wednesday, 08 August 2012 00:00|
Are you keeping up? Do you even know where to start?
Remember when being a triple threat meant RPG-DDS-CL? No more, my friends. Now you need a set of Web-oriented skills to impress people. The problem is, there are so many to choose from. I mean seriously, have you seen the list of Web languages/apps that are out there? So the question becomes, what should your starting point be? What skills are most important to an i professional like you?
Most RPGers are oriented around the "big program" design philosophy: find out what the driver file is going to be for the program you're building and then add in the edits necessary to create one big program. It might be a monster or it might be a reasonable size, but it's still a single program that contains everything (edit logic, display logic, control logic).
The reason for that is relatively simple: RPG has historically been unable to easily (efficiently) call other programs, making it sensible to do things with one program.
But ILE—and especially /Free—makes it not only easy but appropriate to create an application with multiple modules. This allows you to write bite-sized modules that are easy to understand and modify while giving you the ability to use the language that is most suited to the task: PHP for displaying the pages, RPG for edits and logic, stored SQL procedures for data access, etc.
It's definitely a new way of thinking about things, but it's one that you can easily learn. As you approach a task, think about it from a Model-View-Controller (MVC) point of view. What elements are the model, the actual logic that needs to be executed to do this (edits, etc.)? What elements are the controller: how will you move from one screen to another, what function keys are involved, how does everything relate to everything else? What elements are the view: what pages need to be built, and what kinds of data will be entered or displayed?
Once you have everything broken apart by type, you can start creating your programs using the most appropriate language.
Related to this is the use of frameworks, special development environments oriented around a given language that allow you to quickly build an application by using existing components. For example, with PHP you have the Zend framework (and a number of others) that can be downloaded for free. This is something we on the RPG side have resisted. Build programs by using common modules? I don't think so. But other languages and ways of thinking have adopted it heartily.
Generally, when we talk about design in the RPG world, we're talking about the following scenario. Meet with the users (or get an email from them), respond with a design napkin (or send an email back), begin programming, talk to the users when something happens and we don't know what to do about it, demo the application just before moving it to production, and spend the next few months/years modifying the app so that everyone is happy with it. At the end, there are a dozen or so mods listed at the front of the program, and more commented code than unmarked lines.
Web design, done properly, is much more interactive. First, it should take advantage of a scrum project-management style. We often think of scrum as something you use if you have a project team, and most RPG projects are just one lonely programmer working away trying to satisfy a herd of impossible-to-please users. But the essence of scrum is quick iterations separated by a full user review. And that's what we want to get into because even a single programmer can use it. Modular programming assists this, of course, because it allows you to create stub programs so that the app can be demoed almost from day 1. You then keep adding detail to the stubs until your application is all growed up.
And since you have had continued interaction with your users, each time giving them something they could see and play with, chances are you will be much closer to the target than you would be otherwise. And if you're not, since the users have had hands-on usage right from the start, it's very apparent that the problem is more them than you, and let's face it, that's what's really important. Users are like siblings. Even if you love them, it's still fun when Mom or Dad catches them doing something.
OK, on to actual technical skills. And the first one you need is HTML. HTML is a markup language, which means it's not used for logic or if-then garbage or anything except for defining what a Web page should look like. You want to think of it more like the weird markings you used to be able to get in MS Word when you selected "show formatting" for the document.
There are several versions of HTML. The first is like HTML 1.0 to 3.0 or something like that. To be honest, I sort of forget. That's old HTML, and it was somewhat limited. Today, many of its functions are done by Cascading Style Sheets (CSS) or have been eliminated totally, but the basics are still there. The second is XHTML. This is a form of HTML based on XML that was supposed to be the future of HTML until a bunch of the people who had to implement it rebelled. They developed the third flavor, which is called HTML5 ,and after a hard-fought battle where there was plenty of gouging and choking, HTML5 has emerged victorious.
HTML5 has a ton of really cool features. There's just one problem: HTML5 can have all of the features it wants, but they won't work unless the browser you use to view the page supports those features. At the current time, all browsers are working hard to incorporate the features that HTML5 supplies.
The bottom line is that if you use HTML5 on a browser that doesn't support all of it features, the page will still work. It might not be as pretty as it could be, but it will work. So, when you're looking at learning HTML, don't bother with old HTML (like if you have an old book on HTML), just learn HTML5.
And you don't need to know everything. Start with the basics: the markup for the document, header, body, divisions, paragraphs, headers. Of particular importance are using the class and ID because much of CSS uses these tags to point to when applying attributes. Much of what you want to do to make it look nice will be done with CSS rather than HTML5 per se.
In the olden days, everything was done with HTML: colors, formatting, font size, etc. But today, HTML is used mostly to set up the organization of the page, while CSS are used to make it pretty. The general rule of thumb is that content (the actual words you want to appear on the page) should go in the HTML, and the formatting (how it looks) is done via the CSS.
Most good books on HTML also have sections on CSS (CSS3 is the latest version of that) because the two are so closely related. I won't talk about it too much here, but every Web page should have its own style sheet that carries all of the CSS3 formatting information. The important thing to remember is that most CSS3 formats will be applied using a class or ID selector, so it will be important to use those appropriately in your HTML5.
I am in general not in favor of replacing your current DDS-based files and calls with DB2 tables and SQL functions. For 99 percent of database access, there's just no point. Yeah, it's cool and all and some people think it's the only way to go, but like I said, most of the time it's just not worth the effort.
At the same time, SQL is becoming more and more commonplace, especially in the Web world, and many platforms now have support for DB2 SQL access (like Zend's new DBi product). So I guess you have to learn SQL. There are enough SQL books out there that you should be able to do so. Just don't go crazy. Use it when you have to, but if you can use good old DDS, don't feel bad. But you might want to get connected with an SQL forum for really weird things, because really weird things seem to happen with SQL.
PHP or CGIDEV
You seriously don't need to know both. The question is, which should you use? Dude, do you expect me to tell you everything? OK, I will. It's actually an emotional decision. I was listening to a Webinar once with Jon Paris and Paul Touhy discussing this (which to use), and one favored one and one the other. I don't really remember which way it went, but what I do remember is they almost got into a fist fight over it. And this was an audio-only Webinar, and they're very good friends! Like I said, it's a very emotional issue. I chose PHP because it's a valid Web language and I thought it was cool to know a Web language. Chicks dig it, and that's important to me. Both work well. CGIDEV is more RPG-oriented; it's a series of APIs that can be called from within an RPG program. With CGIDEV, you'll use primarily RPG, but to be honest the learning curve for both is pretty similar. And PHP has some awesome array functionality in it. Plus, PHP can be written as procedural (like RPG), but it also incorporates classes and OO functionality, so it's a great way to get your feet wet with the whole OO scene. Bottom line? It's up to you. I honestly don't care.
And that's it. There's lots more you can learn, but that will get you started. Excited? Nervous? Terrified? Yeah, I can dig it. It seems like a lot, and you already know a great deal about RPG-DDS-CL. In some ways, it doesn't seem fair. But who said fairness had anything to do with it, eh, pal? The real question is: Do you want to be cool? Or do you want to be like you are now? Up to you. Slick.
|Last Updated on Monday, 06 August 2012 16:20|