|
Joe,Bryce, I don't want to get into a spitting match here, really I don't. I appreciate how candidly and yet civilly you've made your arguments so I'll take a moment or two to go through them. Take it as a different viewpoint. :)
I don't think you need to know everything listed in this description, but there is no reason that a decently good programmer can't be very familiar with most of it.
I've only been out of school for three years, and while I don't use everything listed every day, I'm familiar with most. And I don't even consider myself one of the best programmers out there.What are you working on? How much RPG programming do you do? Are you the primary point person for a major part of your application suite? Your company manufactures products, so I assume there is ERP involved; are you in charge of things like order entry or MRP or <shudder> accounting?
Modern RPGIV - checkGreat. You know the stuff you learned in school and modern RPG. Frankly, moving to modern RPG from Java is a piece of cake. How about RPG III? Or RPG II? How long do you think it would take you to be make a major modification (or even a minor one!) to an order entry program that uses an internally described display file?
subprocedures - check
use of C or Java functions from RPG - familiar with the approach even if I don't use them, could if I had/needed to.
embedded SQL - check
XML processing - I prefer JSON, but I'm familiar with XML and could pick this up if needed.
RDi - Use WDSC7 until we upgrade
PHP - check
Java - check
.Net - rather not
HTML, Javascript,CSS - check.
When you break it down and look at a span of projects over 3 to 5 years, I really fail to see how having these skills would be that difficult to come by. Unless you are stuck in a shop that does RPGII programming only I would suspect that most programmers on this platform have at least half this stuff in their tool box.Not so, grasshopper :)
Using PHP to generate javascript to generate HTML? Who does that? And why on earth would you? Write HTML where you need it, Javascript where you need it, and keep the PHP on the server doing stuff that can't be done on the client side. AJAX is way more than a passing fad and is quickly becoming the standard for web application data driven development. To develop in a mix'em up/mash'em up way makes for highly unmaintainable and sluggish solutions. Taking a more MVC approach and using each technology as it is intended usually works best in the long run.If you program from the ground up using a Web 2.0 JavaScript framework, then you don't need to code PHP that generates JavaScript. But then again, you don't even need PHP in that case - you simply encapsulate your business logical in RESTful services (in whatever language) and design your pages directly using a decent JS enabled tool.
Joe, I respect everything you have done. You are a great asset to the IBM i community, but I don't think it is very demanding to have the toolbox that Jon and Susan suggest.I respect your opinion and again, I appreciate your candor and civility in expressing it. I hope I've been able to express some of the reality of the world I live in, which is inhabited by those of us with 15, 20, 30 or more years in the field. It's not that we can't learn this stuff, it's that most of us don't have time. At the same time, people do have to upgrade their skill sets so I suggest they eat the elephant one bite at a time, and maybe even ignore some of the less tasty bits ... as you yourself have done with your choice to leave .NET on the table.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.