bb.donnay-software.com

I have polled Xbase++ and eXpress++ developers and have come to realize that a small percentage of them are doing any development for the web. Many don't even have a website or, if they do, the website was not their creation. I started writing web applications back in 1996. I started with a web server named "Website" by O'Reilly. I created my first website by learning HTML and soon I had the ability to connect to my users and show that I was "online" and "web aware". After awhile, it was not sufficient to be able to simply create *.HTM pages with text, .JPG and .GIF files. I found that I needed to have access to my databases so that I could take a web order and save it to a database. I learned about CGI (common gateway interface) and discovered that I could call a Clipper program from the web server whenever an HTML form was filled out and the user clicked on the "Submit" button. This opened up a bunch of new possibilities for me and introduced me to the concept of "Dynamic HTML", i.e. the Clipper program was creating HTML on the fly and sending it to the users Web Browser.

Fast forward 18 years and here we are today with the exact same needs as when we were all running Windows 95 and using Netscape as our browser. Yet, many of those same Clipper programmers have not made the transition. Why is this? I am going to attempt to answer this question. Whether you believe my assumptions are correct or are in error, I want your feedback.

1. Legacy programmers do not clearly understand the paradigm of the "stateless" application and how it compares to DOS or Windows applications.

2. Legacy programmers believe that the concept of web development is so large a paradigm shift that they will NEVER understand it.

3. Legacy programmers often believe that they have to throw away their 20+ years of programming experience and start over again.

4. Legacy programmers are not aware that they can easily leverage much of their code base and experience and increase the usefulness and value of their software by connecting some of it to the web.

5. Legacy programmers often think that they must learn Javascript, Ajax, SSL encryption, PHP, MySQL before they can even think about creating a web application.

6. Legacy programmers often think that the term "web application" means that it must be a huge development effort and that it must rival the functionality of the DOS or Windows application.

7. Legacy programmers are overwhelmed by the enormity of the world wide web and feel that it's a target that is moving so fast they will never catch up.

8. Legacy programmers don't think they can maintain a Windows application and a web application concurrently and that they must be doing one thing or another.

9. Legacy programmers don't understand the relationship between the Web Server and the Web Browser and what is happening under the hood when they type in a URL.

This is just a short list of ideas I have that, I believe, hold back experienced programmers from getting familiar or comfortable with writing for the web. If you want to add to this list or want to critique the list, please give me feedback.

My goal in starting this thread is to try to determine if there are those of you out there who need and want help in this area and how I can provide this help, either by teaching or by adding new features to eXpress++ or both.

I think that Alaska Software has done a remarkable job in bringing us Xbase++ 2.0, even though it is years late and still is lacking in documentation. I intend to use it for all my web projects.

1. Legacy programmers do not clearly understand the paradigm of the "stateless" application and how it compares to DOS or Windows applications.

true

2. Legacy programmers believe that the concept of web development is so large a paradigm shift that they will NEVER understand it.

probably true

3. Legacy programmers often believe that they have to throw away their 20+ years of programming experience and start over again.

probably

4. Legacy programmers are not aware that they can easily leverage much of their code base and experience and increase the usefulness and value of their software by connecting some of it to the web.

true

5. Legacy programmers often think that they must learn Javascript, Ajax, SSL encryption, PHP, MySQL before they can even think about creating a web application.

no, but if they are creating a legit application, they wil have to learn javascript and probably ajax. also, jquery will be very helpful.

7. Legacy programmers are overwhelmed by the enormity of the world wide web and feel that it's a target that is moving so fast they will never catch up.

true

8. Legacy programmers don't think they can maintain a Windows application and a web application concurrently and that they must be doing one thing or another.

you can.. we do.. and, they interact from the desktop direct to the web application and back..

9. Legacy programmers don't understand the relationship between the Web Server and the Web Browser and what is happening under the hood when they type in a URL.

well, it is a completely different world..

rdonnay wrote:I have polled Xbase++ and eXpress++ developers and have come to realize that a small percentage of them are doing any development for the web. Many don't even have a website or, if they do, the website was not their creation. I started writing web applications back in 1996. I started with a web server named "Website" by O'Reilly. I created my first website by learning HTML and soon I had the ability to connect to my users and show that I was "online" and "web aware". After awhile, it was not sufficient to be able to simply create *.HTM pages with text, .JPG and .GIF files. I found that I needed to have access to my databases so that I could take a web order and save it to a database. I learned about CGI (common gateway interface) and discovered that I could call a Clipper program from the web server whenever an HTML form was filled out and the user clicked on the "Submit" button. This opened up a bunch of new possibilities for me and introduced me to the concept of "Dynamic HTML", i.e. the Clipper program was creating HTML on the fly and sending it to the users Web Browser.

Fast forward 18 years and here we are today with the exact same needs as when we were all running Windows 95 and using Netscape as our browser. Yet, many of those same Clipper programmers have not made the transition. Why is this? I am going to attempt to answer this question. Whether you believe my assumptions are correct or are in error, I want your feedback.

1. Legacy programmers do not clearly understand the paradigm of the "stateless" application and how it compares to DOS or Windows applications.

2. Legacy programmers believe that the concept of web development is so large a paradigm shift that they will NEVER understand it.

3. Legacy programmers often believe that they have to throw away their 20+ years of programming experience and start over again.

4. Legacy programmers are not aware that they can easily leverage much of their code base and experience and increase the usefulness and value of their software by connecting some of it to the web.

5. Legacy programmers often think that they must learn Javascript, Ajax, SSL encryption, PHP, MySQL before they can even think about creating a web application.

6. Legacy programmers often think that the term "web application" means that it must be a huge development effort and that it must rival the functionality of the DOS or Windows application.

7. Legacy programmers are overwhelmed by the enormity of the world wide web and feel that it's a target that is moving so fast they will never catch up.

8. Legacy programmers don't think they can maintain a Windows application and a web application concurrently and that they must be doing one thing or another.

9. Legacy programmers don't understand the relationship between the Web Server and the Web Browser and what is happening under the hood when they type in a URL.

This is just a short list of ideas I have that, I believe, hold back experienced programmers from getting familiar or comfortable with writing for the web. If you want to add to this list or want to critique the list, please give me feedback.

My goal in starting this thread is to try to determine if there are those of you out there who need and want help in this area and how I can provide this help, either by teaching or by adding new features to eXpress++ or both.

I think that Alaska Software has done a remarkable job in bringing us Xbase++ 2.0, even though it is years late and still is lacking in documentation. I intend to use it for all my web projects.

Roger

Gbaaam !!! 100% correct.

Joe

Roger & comunity.

Can I begin by saying that this topic of discussion is the remarkable interest for actual existing Xbase programmers.
Really this is a point at which I invest much of my time in research.
I still use the Xbase 1.9 and have an urgent need to integrate Websites (Online Shops) made by other programmers with my applications that still use DBFs.

This challenge can mean losing current customers because these are forced to migrate to other more inclined to Web applications.

Here in Europe, and particularly in Portugal is very evident that all software is migrating rapidly to the Web, Cloud and Online crossplatform apps.

right now my big doubt is:
The Alaska xBase 2.0 fulfills these needs?
The Alaska CXP is the solution?
Renew the Alaska subscription already includes this CXP or is it a separate module or another project for the far-off future?

I think at this time to migrate the programs for the Web has the same meaning as when it was necessary to change the MS-DOS to Windows.
those who can, have the secure future. Others are left behind.
And There is a point that is absolutely right.
Who has not done it's too late.

I think there are many Alaska xBase programmers who do not show or do not have the opportunity to participate live in these discussions and DevCon, for logistical reasons, others for economic reasons.
Programming in xBase is expensive.

Everything that was said in the initial topic of Roger is very relevant and makes perfect sense.
The challenge is to take this matter to the largest possible number of participants.
Would highlight the importance of this call and encourage all participants to express their views on this matter.

I'm sure the result would indicate the obvious conclusion that Roger and we all already know.
the Web is the future ...

Thank you
Regards Bytes & Bits.
Pedro

no, but if they are creating a legit application, they will have to learn javascript and probably ajax. also, jquery will be very helpful.

Brian - I have always believed that people learn by taking baby steps. I totally agree that these skills will be necessary in the long run, but are not necessary to get started and to even have a useful application. If you are writing an online auction app (such as yours), then certainly it will be more legit if you are in a competitive world. I worked with you on this in the early days and your web app seemed quite legit to me before you learned all of this. Look at all of the legit eXpress++ apps there are now. Yet, half of the developers still don't write in object oriented code. Ask any non-eXpress++ user if it is possible to write a GUI Xbase++ application without knowing OOPS and they would laugh, yet there aren't any eXpress++ users who are laughing.

It will not be easy to develop an eXpress++ type concept for web applications, but CXP is a big step toward getting there.

The Alaska xBase 2.0 fulfills these needs?
The Alaska CXP is the solution?
Renew the Alaska subscription already includes this CXP or is it a separate module or another project for the far-off future?

Pedro - Yes, if you are an Xbase++ programmer, have an Xbase++ application, and have many years of Xbase++ experience, then CXP is a very logical solution. Xbase++ 2.0 fills these needs as well as any other language (and even more if you have Xbase legacy experience and code base). The same kind of questions are being asked now as were asked in 1999. Clipper programmers were wondering if they needed to learn Delphi, Dot-Net, C#, etc. to write a robust Windows applications. The answer was NO. Xbase++ fulfilled those needs. ActiveX, ODBCDBE and ADSDBE wasn't in Xbase++ when we all started, but that didn't stop us because it was still the best tool for our needs at the time. The Alaska professional subscription includes everything that is needed.

I think there are many Alaska xBase programmers who do not show or do not have the opportunity to participate live in these discussions and DevCon, for logistical reasons, others for economic reasons.
Programming in xBase is expensive.

Pedro - The cost of programming tools is expensive only if you don't use them. It is very expensive to keep buying software that you find will not work for you. But when you realize that it IS working, the cost is cheap compared to the cost of the huge waste of time. I value my time at $60 per hour. I have charged that same rate for 15 years now. If I were to spend $1000 on some software that would save me 100 hours of valuable time, or increase my customer base, I would be way ahead. Logistics is not an issue any more. The web and this forum have proven this to be true. I have many customers who I have worked with but have never met in person. I used to have to take trips to New York City to work with Bobby Drakos on his Taxi software. I haven't been there in years because we now work via Teamviewer and Skype. Instead of flying all over the country every year, like I used to do, I now save that valuable travel time and use it to ride my motorcycle all over the American West. I am able to do this because I use and teach Xbase++.

My experience tells me that I learn very little about how to program at software conferences. I am always too busy teaching to attend other seminars, but what I always do learn is who are the people who are bringing us these solutions, and can I depend on them to support the software. The key programmers at Alaska Software have been the same team for years. I have known Steffen Pirsig for 15 years now. That is 7 more years than Nantucket was in business. We have all been frustrated because it has taken so long for them to get this far. I now know why this is so. It is because the FoxPro community has been the driving force for the past 5 years. Microsoft announced that they have dropped support for FoxPro. These people are very web-aware, because they were introduced to "Active Pages" years ago and know how important ASP and MsSQL was to their productivity and their business. For Alaska to assimilate this new community, they had to offer a lot of new stuff. They decided that the web stuff was more important that a screen designer, because that's where application development is headed.

Their biggest problem has always been "getting the message out". Alaska Software is a technology-driven company, not a market-driven company.

I have been sitting on my hands for about 5 years now, doing very little new development. eXpress++ has been mostly in maintenance mode, the same as Xbase++. I say I am "semi-retired" and have been looking for full retirement because I have become bored with programming. I came back from the conference in Phoenix with a new attitude. Why? Because the programmers at Alaska Software have been showing a new attitude and the FoxPro people have been showing a new attitude. Half the people in my Xbase++ for Newbies seminar were FoxPro users. I now want to learn all the new stuff and Andreas Herdt at Alaska has been very cooperative. When I don't find an answer in the documentation, I send him an email and I get a quick response. When you understand that Alaska is more reactive than they are proactive, you finally understand the rules of the game.

The other thing that impressed me greatly was to learn how committed Steffen Pirsig is to this venture. The reason that Alaska was slow to react was because of the large scope of the Xbase++ product. As their customer base grew and their product grew, it took longer and longer to validate and certify the product. Steffen told us, in one of his seminars, that it used to take 2 weeks to certify a build because, even running 24/7 the testing software took that long. To solve this problem they invested in over 100 virtual servers and solid state drives. That time has been reduced now to 2 hours. This means that they are prepared to give us continuous updates to the runtime, the help system and the workbench. This is a huge step forward for Alaska and a big investment on their part.