Hmmm, if I could learn PB all over again, how would I do it?
- Come to PB with a healthy understanding first of SQL. If your app is hitting a database, PB is very good at that, but not understanding SQL well when I was younger lead to poor decisions. Well written SQL will help you with application partitioning, performance, and centralization of logic. I have found that good use of SQL can significantly reduce the amount of "crufty cobble-on PB client code" that tends to congregate around datawindow code commonly written by less experienced developers.
- With a good understanding of SQL you should have a healthy understanding of result sets. That's a big part of appreciating the power of the datawindow and datastores. In PB, the datawindow is everything. I'd start by using the datawindow simply as a report maker to drive home how it retrieves data, and the power it gives you in graphic presentation control.
- Develop knowledge of PB script. It's not that hard, but it has some quirks. Learn how to manipulate the datawindow with PB script, how to make it interact with other controls.
- Sybase offers PB classes. Take one of the fast track courses to get an overview of how to do things in the tool. If your company wants you to learn this but is too cheap to pay for professional training...you may want to reconsider where you work. Investing in employees is what separates the good employers from the mediocre ones.
- If you understand object orientation, that will help you write a potentially better and easier-to-maintain app. Even if you're in the position of only being able to cobble-on to an existing app (welcome to my world) then future enhancements to that app can be designed to introduce better approaches and fewer complications. You can't fix the old stuff overnight, but you can make sure the new stuff generates less production support than the old stuff; if you can increase the functionality of the app while keeping support needs level, you've won at least a little victory under difficult circumstances.
- If you're inheriting an existing app, doing production support is a good way to get broad, if random, exposure to the app. If it's a legacy PB app with any age on it, it's probably poorly designed, poorly written, poorly documented, and not very object oriented. Build experience with the app and gain familiarity with it before attempting refactorings; there are probably all kinds of hidden dependencies in it.
If you are fortunate enough to be starting from scratch, then make a prototype and learn from it what a mess it is to maintain a pile of crap where code is splayed through GUI objects. Be careful to avoid coding around the datawindow's built-in support for concurrency control, and to avoid tons of embedded SQL in the script. Then throw the prototype away and consolidate business logic in PB non-visual objects or even database stored procedures; you want to put reusable business logic in the most centralized place, and that place is not in a button or custom event on a window.
Books and Tutorials
- There aren't many PB books being published these days, but if you're doing classic PB, there is a good PB9 Advanced Client/Server Development book by Bruce Armstrong.
- The PB manuals have lots of information, and if you are using the Powerbuilder Foundation Class, it has been open sourced. You can get it at Sybase CodeExchange.
- There are some good sites out there. Fellow Stackoverflow user Terry Voth has a great one. I also like Ken Howe's PB tips site.
- There are some PB newsgroups with good information. And other resources too; Google will help you a lot here.
- PowerBuilder Developer's Journal doesn't have as many classic PB tips and examples as it used to but most of the old content I believe may be available online.
Random Things
- I'm hoping your shop uses source control. If not, figure it out and get that going. Then look into PB ORCA Script. I started using this to automate our builds and it's a time saver. There's a chapter in the PB9 Advanced Client/Server book on it, but also some good examples at CodeExchange.
- If you're new and under the gun, you'll probably find yourself many times thinking, "I can get that data easy by slapping in an embedded SQL statement here". Be careful about that; quick hit, single row, retrieve-only queries can be ok, but misuse of embedded SQL in your app makes it hard to maintain.
- If you're new and under the gun, you'll probably find yourself many times thinking, "I can get that data to look the way I want by throwing in some code in the retrieve row or retrieve end events". Be careful about that too. Retrieve row logic will hurt performance. I've seen retrieve end logic often used to do additional processing and add data to the datawindow; this is much better done as part of the datawindow's original SQL statement rather than by adding more cruft to the datawindow control scripts.
- It's not all just about learning PB. Learn your company's business and understand the processes your system is supposed to help with. Sometimes the solution's complexity isn't fixed by automating it with a system, but by getting the authorized parties to recognize that a process can be simplified on the business side first.
- People get so worked up about new languages; I'm not an exception and really want to do more with .Net and others. But it is your commitment as a developer that makes the difference; you can do great things in any language, be it PB or VB or Delphi or .Net. Your constituents don't really know or care what the app is written in if it helps them get work done.