User:Gary J Hardy
This is a Wikipedia user page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/User:Gary_J_Hardy. |
Gary J Hardy | |
---|---|
Born | Gary John Hardy August 26, 1952 |
Nationality | American |
Citizenship | United States of America |
Education | Chemical Engineering |
Alma mater | University of New Hampshire, Durham |
Occupation | Software Engineer |
Spouse |
Suzanne Hardy (m. 2002) |
Website | www |
Gary J Hardy (born August 26, 1952), is a Professional Software Engineer working in the computer software industry since 1982. Developing software at; Apple Computer, Digital Equipment Corporation, EarthLink, General Electric, IBM, Intel, Netscape, Sun Microsystems, Dun & Bradstreet, as well as many other small to medium sized companies.
For the record. There are three reliable, mature, broadly understood non-COTS enterprise application platforms/frameworks circa 2014; JEE, LAMP, and .NET. For a number of years my development efforts have been focused on leveraging two of those well-understood technology stacks; Java Enterprise Edition and the open-source Linux stack. Effectively and efficiently capitalizing on those technologies to meet current business needs is always my primary goal. Dealing with the known limitations for a project’s/product's server technology stack [e.g. tomcat/java/spring-mvc/apache-cxf/hibernate/rdbms] vs. “exploring” the unknown limitations of a new [and, in theory, improved] technology is almost never in the best interest of any business. Put another way. Enterprise architecture [and development thereof] must be 99% solid product development and 1% R&D to succeed.
With all that said, if the new technology frontier is non-browser based mobile computing with a fat[-ish] client/server model then 24/7 back-end reliably will be critical. That is not only full-circle from the 1980's/90's but what I firmly believe can be achieved with current resources [people] and tools [JEE/LAMP] available today.