Hello there folks, I'm looking to get some feedback from the hive mind of this group. And, I will admit, I'm doing this kind of last minute. Too many things going on lately, and I have not had a chance to do my true due diligence! Such as thorough research via prior postings in this forum.
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently, that's the reason I'm going down to LA for an in-person interview, since the last interview I did via Skype. It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP. I suspect its also because the 1 and only programmer there, who's been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition! They are asking me to propose what I think is the best option. They have mentioned several options such as Fox-in-Cloud, the Alpha software, and even Servoy. They did not bring up things like Lianja, XoJo, or X# the open source X-base language.
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
They also told me that they have already been working with Alpha SW - and in discussions with them for several months. Which makes me think they are already leaning towards Alpha. A quick review of old postings in this forum did not show a lot of discussion or users of Alpha. It would really be great to hear from some Alpha users!
Anyway - any and all input would be greatly appreciated. I've seen Numerous discussions about a number of these technologies here in the forum over the years. But, honestly - I never truly got involved with any of them - until NOW!
Regards, Kurt
Kurt, I used Alpha 4 and Alpha 5 quite a lot about 12-15 years ago and it was a good solid XBase RAD platform but limiting in what it could do programming wise. Looking at their website it has obviously matured a great deal, the emphasis being on device independent application development. Well worth a look I think and must admit I am tempted myself!!
Dave Crozier Software Development Manager Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd T 01706 222 792 E DCrozier@flexipol.co.uk W https://www.flexipol.co.uk/ Follow us: Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the risk of virus transmission through email and therefore any files sent via e-mail will have been checked for known viruses. However, you are advised to run your own virus check before opening any attachments received as Flexipol Packaging Ltd will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate virus protection.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Terms & Conditions: Notwithstanding delivery and the passing of risk in the goods, the property in the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds payment in full of the price of the goods and all other goods agreed to be sold by the seller to the buyer for which payment is then due. Until such time as the property in the goods passes to the buyer, the buyer shall hold the goods as the seller's fiduciary agent and bailee and keep the goods separate from those of the buyer and third parties and properly stored protected and insured and identified as the seller's property but shall be entitled to resell or use the goods in the ordinary course of its business. Until such time as the property in the goods passes to the buyer the seller shall be entitled at any time -----Original Message----- From: ProFox profox-bounces@leafe.com On Behalf Of Kurt at VR-FX Sent: 20 March 2019 05:45 To: ProFox Email List profox@leafe.com Subject: A FoxPro Transition @ UCLA...
Hello there folks, I'm looking to get some feedback from the hive mind of this group. And, I will admit, I'm doing this kind of last minute. Too many things going on lately, and I have not had a chance to do my true due diligence! Such as thorough research via prior postings in this forum.
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently, that's the reason I'm going down to LA for an in-person interview, since the last interview I did via Skype. It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP. I suspect its also because the 1 and only programmer there, who's been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition! They are asking me to propose what I think is the best option. They have mentioned several options such as Fox-in-Cloud, the Alpha software, and even Servoy. They did not bring up things like Lianja, XoJo, or X# the open source X-base language.
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
They also told me that they have already been working with Alpha SW - and in discussions with them for several months. Which makes me think they are already leaning towards Alpha. A quick review of old postings in this forum did not show a lot of discussion or users of Alpha. It would really be great to hear from some Alpha users!
Anyway - any and all input would be greatly appreciated. I've seen Numerous discussions about a number of these technologies here in the forum over the years. But, honestly - I never truly got involved with any of them - until NOW!
Regards, Kurt
[excessive quoting removed by server]
Hi Kurt,
"they know it's a dead language":
- technically false: even if Microsoft no longer provides extensions, many 3rd party initiatives keep it alive: west-wind, VFPx, VFPA, FoxInCloud, and many others. VFP remains competitive on desktop and web.
- humanly: hen and egg story and self-fulfilling prophecy; the more we advocate on how far we can expand the existing VFP code base to new horizons (web, 64 bits, etc.) the more interest we can grow on VFP. The more we internalize that we're dying, the more likely it'll happen.
About FoxInCloud,
"Conversion Assistant" is in fact an "Adaptation Assistant" (FAA): with FoxInCloud the same code base can be deployed on either the desktop or the Web, just by adapting the existing code base with the help and guidance of FAA (and our support of course)
"making updates to the system actually means programming in something that is not actually FoxPro"
FoxInCloud runs the application on the server (reason why the code is adapted), and replaces the VFP UI by a HTML/CSS/JS user interface, tied to the server by the user events (click, valid, etc.) through AJAX.
- Adding new functionalities generally requires some VFP development that you can test in desktop mode before moving to the Web.
- Improving the user interface (eg. adding features that VFP does not support such as animations, rounded corners, gradients, etc.) requires CSS/JS coding that you can implement in an application-wide file (css and/or js) or encapsulate within your VFP classes.
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
VisitFoxInCloud Blog http://foxincloud.com/blog/ WatchFoxInCloud Marketing Videos https://www.youtube.com/channel/UCUzzqO5375-fA7dLDds-wOQ WatchFoxInCloud Technical Videos https://www.youtube.com/channel/UCrEohAtbuf3uOXBH2pjp5Vw Stay tuned onFoxInCloud Roadmap http://foxincloud.com/roadmap.php Learnhow to use FoxInCloud http://foxincloud.com/how-to.php DownloadFoxInCloud Adaptation Assistant http://foxincloud.com/download.php for free
Le 20/03/2019 à 06:45, Kurt at VR-FX a écrit :
Hello there folks, I'm looking to get some feedback from the hive mind of this group. And, I will admit, I'm doing this kind of last minute. Too many things going on lately, and I have not had a chance to do my true due diligence! Such as thorough research via prior postings in this forum.
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently, that's the reason I'm going down to LA for an in-person interview, since the last interview I did via Skype. It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP. I suspect its also because the 1 and only programmer there, who's been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition! They are asking me to propose what I think is the best option. They have mentioned several options such as Fox-in-Cloud, the Alpha software, and even Servoy. They did not bring up things like Lianja, XoJo, or X# the open source X-base language.
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
They also told me that they have already been working with Alpha SW - and in discussions with them for several months. Which makes me think they are already leaning towards Alpha. A quick review of old postings in this forum did not show a lot of discussion or users of Alpha. It would really be great to hear from some Alpha users!
Anyway - any and all input would be greatly appreciated. I've seen Numerous discussions about a number of these technologies here in the forum over the years. But, honestly - I never truly got involved with any of them - until NOW!
Regards, Kurt
[excessive quoting removed by server]
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
If they want to move to something similar to VFP and minimise the transition then they might as well stay on VFP and possibly FoxInCloud.
Move away from VFP or minimise transition, pick one. Even something like Lianja which supports VFP syntax to a large extent will involve significant retooling. X# isn't there yet for VFP syntax. Servoy is a Java web stack that you code in JavaScript. XoJo is BASIC-like. Don't forget LiveCode while we're at it.
On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX vrfx@optonline.net wrote:
The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently,
I'm sympathetic to your situation, but you don't want the wrong interviewer hearing that you're too busy babysitting parrots to interview for a job. That's harsh, and you might not want to work for such a jerk, but you don't want to raise red flags, or even questions, during the interview process, OTOH, you don't want to work for jerks, either. OTOOH, they're paying peanuts and desperate for Fox expertise. Your call,
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
A 30 year's experienced app developer may have some real legacy stuff in their app, and conversion can be a large undertaking. Along with a parallel investigation of what the client needs the app to do is an audit of what the application already does, Whil's Developer Guide went into this in some detail, and I presented a series of lectures with checklists and software for an initial audit.
So, the answer to the question on what they should do is to ask what they want, and what they have? How many lines of code? How many tables? How many fields? Where's the ERD? How many output documents, reports? Where does the data come from? Where does it go? What's the IT infrastructure? What kind of data servers do they support? What kind of maintenance windows are allowed? Where are the users? How do they access the data: PCs, laptops on the road, tablets, phones, embedded in other services? How responsive does the app have to be? What happens in case of failure? What's the backup strategy? What's the disaster recovery plan?
I suspect its also because the 1 and only programmer there, who's
been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition!
It's likely your job is to learn everything the old Obi-Wan knows and become the new master. Realistically (and perhaps this isn't an interview topic), you'll keep the old app running for some time as you transition the data model, the business model, the services model and the interface(s) to the new platform.
They are asking me to propose what I think is the best option.
When a consultant tells me they have the solution to all of my business needs by replacing a 30-year-old system with whatever they are selling, on the first meeting, sight-unseen, I would be rightfully skeptical.
The right answer is that they need to let you learn the app and research the right solution. If you can convince them you are knowlegeable about what is available, and what the issues are that need to be addressed in a migration, then they should hire you to do your job.
There are a lot of good resources out there, like this list, the FoxWiki, books, whitepapers, but you will need to do the footwork. See if you can convince them to pay you to do that.
On Mar 20, 2019, at 6:28 AM, Ted Roche tedroche@gmail.com wrote:
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
I would echo everything Ted brings up. A 30-year-old app will have many layers of functionality, and probably does a bunch of things that most people who use it don’t know about, but one or two people absolutely rely upon.
The main perspective I would add is that you should ask them if they want to keep it as it has been, or if they want to create something that will last for the next 30 years. During my career as a consultant, there were many times that I was brought in to make a particular change the customer wanted. Instead of just saying “Sure, I can do that!”, I would probe a bit. I’d ask them *why* they feel they need this change. I would ask them if there were any other parts of the system that they felt didn’t do just what they needed. Once you get them talking, listen! They thought they knew what they wanted, but almost always I was able to discern their true needs. When a plan to implement those needs was presented to them, they were usually so excited that any questions about my rate were forgotten.
And I’m sure you know what I’m going to suggest next: if they truly want an app that will take them through the next 30 years, don’t keep it in VFP. If they think finding people who know VFP is hard now… well, the situation isn’t going to get any better over time. And it would be unethical for you to advise them on a path that may be good for you but hurt them in the long run.
To sum up: tell them you will need to take the time to learn just what is needed from the app, both in current functionality and future capabilities, and then and only then could you suggest a path forward. That path should involve a programming language (or languages) that have a strong likelihood of being active for the next decade or two.
Take this as a personal opportunity to learn and grow your skillset. I never get tired of learning a new language or a new way of doing things. That, to me, is the hallmark of a true developer.
-- Ed Leafe
On Wed, Mar 20, 2019 at 7:28 AM Ted Roche tedroche@gmail.com wrote:
They are asking me to propose what I think is the best option.
And I want to go back and hammer on this point one more time: they are asking you to tell them, for free, what they should spend the next decade doing. They are asking for consulting for free. They may not even have a guy that's retiring, they just want 30 experts to come in and tell them, FOR FREE, what they should be doing next. Then, they can send the 30-years-experience guy to school for the new thing, and look how much money they save!
No work on spec.
YOUR job , in the interview, is to convince them that you are the person qualified to work for them to answer that question. You show them that by asking more questions about the application than they can answer to show that you see the need to plan ahead, analyse the situation, research and design the optimal solution. Prove that you are qualified in the interview. Then, they can hire you to solve their problems.
As a consultant, I have had to fall back to the line that "I can only give advice as part of client-consultant contractual relationship."
I agree with all of your points, Ted. They want to move to something and they are not forthcoming in the entirety of the why change.
Is it to get rid of the other guy who may be a great coder as well as a great PITA? Is there a new directive within all of IT to embrace modern technology?
Are they really looking for an Architect to lead the product into Angular and python type of app that they can point to?
On Wed, Mar 20, 2019 at 8:30 AM Ted Roche tedroche@gmail.com wrote:
On Wed, Mar 20, 2019 at 7:28 AM Ted Roche tedroche@gmail.com wrote:
They are asking me to propose what I think is the best option.
And I want to go back and hammer on this point one more time: they are asking you to tell them, for free, what they should spend the next decade doing. They are asking for consulting for free. They may not even have a guy that's retiring, they just want 30 experts to come in and tell them, FOR FREE, what they should be doing next. Then, they can send the 30-years-experience guy to school for the new thing, and look how much money they save!
No work on spec.
YOUR job , in the interview, is to convince them that you are the person qualified to work for them to answer that question. You show them that by asking more questions about the application than they can answer to show that you see the need to plan ahead, analyse the situation, research and design the optimal solution. Prove that you are qualified in the interview. Then, they can hire you to solve their problems.
As a consultant, I have had to fall back to the line that "I can only give advice as part of client-consultant contractual relationship."
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
Ted - I must say - your answer is Brilliant! Although it may have seemed obvious to you - it wasn't obvious to me. However, I was feeling a LOT of pressure to give them the kind of response they requested - and now I know WHY - since I was given a nearly impossible task. As you stated, one can NOT truly make a reasonable suggestion without thorough research and review!
Thank you Ed & Stephen for your corroboration - I really appreciate it.
On 3/20/2019 4:28 AM, Ted Roche wrote:
On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX vrfx@optonline.net wrote:
The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently,
I'm sympathetic to your situation, but you don't want the wrong interviewer hearing that you're too busy babysitting parrots to interview for a job. That's harsh, and you might not want to work for such a jerk, but you don't want to raise red flags, or even questions, during the interview process...
Actually - during the interv iew process they did ask me what I am currently doing. And, they actually got a kick out of the bird hotel & my teaching work. But, truth is - its the family death that's also having a impact. And, the boss suggested postponing the interview - and I originally said no.
OTOH, you don't want to work for jerks, either. OTOOH, they're paying peanuts and desperate for Fox expertise. Your call,
Your Jerks comment is funny - and I can understand - since the pay is so low. But, I'm not going to say anymore on that topic.
Am rushing to make these replies - then shower & get the hell out of here - since I have a long drive to go between SF & SD - and a deadline about 7pm!
-K-
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
A 30 year's experienced app developer may have some real legacy stuff in their app, and conversion can be a large undertaking. Along with a parallel investigation of what the client needs the app to do is an audit of what the application already does, Whil's Developer Guide went into this in some detail, and I presented a series of lectures with checklists and software for an initial audit.
So, the answer to the question on what they should do is to ask what they want, and what they have? How many lines of code? How many tables? How many fields? Where's the ERD? How many output documents, reports? Where does the data come from? Where does it go? What's the IT infrastructure? What kind of data servers do they support? What kind of maintenance windows are allowed? Where are the users? How do they access the data: PCs, laptops on the road, tablets, phones, embedded in other services? How responsive does the app have to be? What happens in case of failure? What's the backup strategy? What's the disaster recovery plan?
I suspect its also because the 1 and only programmer there, who's
been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition!
It's likely your job is to learn everything the old Obi-Wan knows and become the new master. Realistically (and perhaps this isn't an interview topic), you'll keep the old app running for some time as you transition the data model, the business model, the services model and the interface(s) to the new platform.
They are asking me to propose what I think is the best option.
When a consultant tells me they have the solution to all of my business needs by replacing a 30-year-old system with whatever they are selling, on the first meeting, sight-unseen, I would be rightfully skeptical.
The right answer is that they need to let you learn the app and research the right solution. If you can convince them you are knowlegeable about what is available, and what the issues are that need to be addressed in a migration, then they should hire you to do your job.
There are a lot of good resources out there, like this list, the FoxWiki, books, whitepapers, but you will need to do the footwork. See if you can convince them to pay you to do that.
My 2 cents (after I wrote this, I realize this is more like a dissertation than a "quick" thought... sorry).
First, grab all those questions Ted mentioned and organize them. You will want to use them - maybe at the end of the interview when they say "do you have any questions for me?" (The "experts" say having active questions about the project/employer puts a big "+" to you with the interviewer). You may know the answers to some already.
I also agree that you should not postpone the interview. Try taking some time today, 15-30 minutes here and there, writing down your prep. Make sure and "write down" things. I bet by the afternoon you'll feel comfortable about the interview. Remember, they ARE LOOKING for help, and you know you can help them.
As for proposing a solution: first, sure, take in what folks on this list say, but evaluate what you think is reasonable and beneficial for YOU. The last thing you want is to recommend something based on what buzzwords you think they want to hear (that they probably don't understand anyway), and then having the nightmare of trying to deliver it. Next, "frame" your recommendation to them - in other words, drop out a few bullet points before going into the recommendation. For example: - need absolute minimal disruption to users of current application (emphasize more or less based on what you know about their 'concern' or usage or admiration of the current application) - want a smooth transition from current developer (assuming "transition" is definitely in their mind, so word this accordingly - key point, show you view the current developer as a key resource - unless you know they are flat out angry with him in some way - in that case, focus on "functional" transition - aka do not lose functionality) - want to move out of current environment quickly (I assume the current environment is something like the app is on individual workstations, connected to a network drive/DB, etc) - need an expandable/adaptable platform for their business cases (or functional needs, or some other non-corporate term since this is a university) - cost is important - initial as well as yearly recurring - [if you know of a couple other things they have greatly emphasized, repeat them here - but don't repeat them if they were purely technology statements - e.g. if they've said several times "We need to move this onto .Net" or something like that - don't repeat that here. Those kind of statements show a lack of strategic thinking on their part. But if they've said things like "integrating with our other university systems" - that is a true business/functional goal so it would be good to repeat here (and VFP can do that quite easily - remember, in the end, it's all about the data).
Then this is the kind of outline I'd use 1) start off with FoxInCloud - cost is low, extremely low risk of functional loss, immediate ability to expand functionality, but may need significant server power 2) while maintaining with FoxInCloud, carefully research other platforms for potential code conversion, determine: up front cost, maintenance cost, licensing fees, staffing needs 3) quarterly review research, redirect focus accordingly - it could well be FoxInCloud will be shown the superior long-term solution as well 4) if a rewrite into another platform is chosen, develop deployment plan, incorporating user-noted critical operations (e.g.- "no matter what, make sure I never lose my course material", "make sure I always have that pop-up option copy something to my calendar" , or whatever)
This approach gives them time to carefully evaluate alternatives with extremely low risk of losing functionality or usability, while moving into an easier manageable/deployable domain (aka web/browser - although I have to laugh at that... more info at the end of this message). At the same time, it brings on a valuable resource - YOU - that can help them into a long-term path for this application and maybe others.
Now, if they push about alternative platforms you're aware of: 1) C#/.Net - expensive long-term (licensing/MS updates/deprecations), high risk of long schedule and/or functional/degradation during conversion, but many resources available (at a price) 2) Apache - PHP - Javascript/frameworks - low expense, probable functional degradation/loss - or significant time to replicate, many resources available (but pricey if need to hire consultants, etc) 3) Alpha - somewhat expensive, probable functional degradation/loss (only FoxPro 2.6 table access - advanced VFP database stuff not available), may take significant time to "convert". But BE CAREFUL in talking about this one - it sounds like they have already been exposed to months of "marketing talk" - so you have to be careful about sounding negative on this. You MIGHT mention it is proprietary, so you think it would be a good idea to do independent, detailed technical deep-dives before choosing it. Also, do more research on the Alpha website before the interview - look for comments on the Web. 4) Servoy (you probably should do a quick look at their website, etc. I looked at them but decided it would be a huge rewrite of my code base, etc - not to mention expensive the last time I checked) 5) X# is a possibility, and may be a low-risk translation when VFP syntax becomes available, but need to be wary of potential costs (.Net? - aka, look at what Oracle recently did with Java licensing...)
One thing that may come up is security. If you go with the FoxInCloud as the starting point, talk to Therry - get some points about how that platform addresses security. If you don't feel comfortable talking about HTTPS, TLS2.0, certificate management, man-in-the-middle attacks, blah blah blah, don't bring it up yourself (sorry about the buzzword drops). They may not even be aware of the massive attack vectors they are opening by moving an application to the "web" - but at least be prepared to give a few points about your primary proposal if they ask about it.
So, again, with the above alternatives, you need to look at this from YOUR angle. But let me try to put your mind at ease. None... and I mean ABSOLUTELY NONE, of all the latest fads of languages, platforms, blah blah blah, are conceptually much different than what you already know about developing applications. The challenge is the massively different SYNTAX and TERMINOLOGY they use (as time goes on I'm becoming more convinced that platforms that created "new" syntax/terminology did so for marketing, and not technical, advancement). JVM? -> VFP runtime files. Client-server? -> buffered data (yes, much more, but conceptually think extra steps to "commit" data, etc). APIs? -> object methods (but the object could be MASSIVE, a whole application unto itself). I am over-simplifying to a degree, but if you have developed the ability to solve complicated problems in VFP, then you have the ability to translate and internalize all the latest and greatest buzzword platforms so that you could use them yourself. Note: if you go that route, you will likely be frustrated and amazed at the "backward leaps" some of these "advanced technologies" are as compared to VFP - hahahahaha.
Sorry, this is too long already, but let me add a couple things. With the FoxInCloud, you may want to talk with Therry directly about costs. I think the base license is only 10 concurrent users. That may not be adequate for how the current application is used. I could not find the additional license fees on their site, so I'd say talk to him privately. Just make sure you have some good estimates you can put in front of them.
Now look at the above and make it all YOUR OWN. If you don't like something or are uncomfortable with it, toss it out. If you know of something else that interests you, add it. At the end of the day this is about matching you to a job. The key point is if you feel you would be willing to dip into other technologies/platforms (albeit, generally inferior ones), then you want to be clear you have that ability. And that will require a little research - hopefully the above gives you some starting points.
If I recall, this interview may be more of a "code test" regarding VFP. If so, that's great, you have no worries. Then, if they start talking about the future and what path you would take, just be confident in what you are proposing, and know WHY you are proposing it. They need help, you can readily provide it.
I'll end by briefly talking about 2 things: 1) I have NEVER seen a "good" rewrite of any of my VFP applications (I've seen it attempted 5 times). 3 of the 5 ended with a loss of about 50% functionality - about 400% higher maintenance costs (aka licensing, personnel), and limited (or expensive) expandability - but hey, it runs in a web browser (the client was very upset to say the least). In another, a gov agency was providing software to help companies "file" data -Â the gov decided it did not want to distribute VFP apps and so tried to convert to a web-based .Net thing. After about 18 months (I think, I didn't stay there until the end), they gave up the conversion effort and decided to just publish a "data format" - so the companies had to go pay for their own software development to create the filing (I thought about tapping into that, but the insanity at the gov organization and the filing companies really put me off - and I had other cool things sitting in front of me <g>). For the last one, the conversion went on for about 2 years I think (not sure I wasn't there), but apparently they gave up on that too. It turns out they are still using my VFP application (actually several of them on the same "specialized framework"). This is 20 YEARS LATER! ROFLMAO - thinking back to some of the "discussions" I had with MS .Net certified experts, how they told me VFP is not a viable long-term platform, it could not support complicated business needs.... hahahahaha... all the apps those guys worked on... ALL OF THEM - have gone the way of the dodo bird - and those VFP apps are chugging along.
Sorry... not brief at all... but number 2) is, guess what.... Rich Client Applications have won the war. Of course, most "web vendors" are trying to hide that fact. But if you look at the "advancements" in Javascript - they are all about client-side processing. They recently put things in like "service workers", and "indexed database" (different term? - can't remember), local cache management... Oh... my.... god. I recently finished a "nanodegree" in front-end web development and when we got to those "advancements" I really nearly fell out of my chair laughing. All these things ALL OF THEM I did in VFP like 20 years ago (server application - distributed VFP apps - with West-wind as the 'linking' piece). And the claims about web applications being easier to deploy and easier to maintain.... oops... I really almost fell out of my chair laughing again. In that course, I spent maybe 40% of the time "debugging" the freakin' framework they wanted us to use (Angular, Vue, React, Ember, Jasmine, blah blah blah). But to be fair, some of those things are getting close to the stability and reliability that VFP has. I heard recently (on this list?) that maybe Python and other languages are going to be "natively" available in browsers soon. I sure hope so. Javascript is interesting, but it is not object-oriented, and it's been "functionally patching" itself like crazy and thus has a lot of quirks that get in the way (and create maintenance nightmares).
Ok, those last 2 paragraphs were a digression. I was trying to give you confidence that you can indeed pick up any of the advanced--- oops, threw up in my mouth a little... So let me say, pick up any of the "newer" platforms. For me, the best way to learn them is not necessarily "courses" (nor "certification programs"), but to build something "real" with them. If you land this job, you can help the employer in the near-term and then learn those other platforms and help them pick the "right" one (instead of the best-marketed one). I would also say, do not make the interview about a defense of VFP - instead, make it about you being a resource that can reliably meet their near-term needs as well as their long-term needs.
Wishing you the best of luck.
HTH, -Charlie
On 3/20/2019 7:28 AM, Ted Roche wrote:
On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX vrfx@optonline.net wrote
The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently,
I'm sympathetic to your situation, but you don't want the wrong interviewer hearing that you're too busy babysitting parrots to interview for a job. That's harsh, and you might not want to work for such a jerk, but you don't want to raise red flags, or even questions, during the interview process, OTOH, you don't want to work for jerks, either. OTOOH, they're paying peanuts and desperate for Fox expertise. Your call,
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
A 30 year's experienced app developer may have some real legacy stuff in their app, and conversion can be a large undertaking. Along with a parallel investigation of what the client needs the app to do is an audit of what the application already does, Whil's Developer Guide went into this in some detail, and I presented a series of lectures with checklists and software for an initial audit.
So, the answer to the question on what they should do is to ask what they want, and what they have? How many lines of code? How many tables? How many fields? Where's the ERD? How many output documents, reports? Where does the data come from? Where does it go? What's the IT infrastructure? What kind of data servers do they support? What kind of maintenance windows are allowed? Where are the users? How do they access the data: PCs, laptops on the road, tablets, phones, embedded in other services? How responsive does the app have to be? What happens in case of failure? What's the backup strategy? What's the disaster recovery plan?
I suspect its also because the 1 and only programmer there, who's
been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition!
It's likely your job is to learn everything the old Obi-Wan knows and become the new master. Realistically (and perhaps this isn't an interview topic), you'll keep the old app running for some time as you transition the data model, the business model, the services model and the interface(s) to the new platform.
They are asking me to propose what I think is the best option.
When a consultant tells me they have the solution to all of my business needs by replacing a 30-year-old system with whatever they are selling, on the first meeting, sight-unseen, I would be rightfully skeptical.
The right answer is that they need to let you learn the app and research the right solution. If you can convince them you are knowlegeable about what is available, and what the issues are that need to be addressed in a migration, then they should hire you to do your job.
There are a lot of good resources out there, like this list, the FoxWiki, books, whitepapers, but you will need to do the footwork. See if you can convince them to pay you to do that.
How FoxInCloud addresses security
1- FoxinCloud supports https; eg. https://dooxi.fr/index.doo
2- requests from FoxinCloud client always include the same data and NEVER include SQL queries (prone to SQL injection), only user events (eg. Click, Change, Blur, etc.) and values:
Here are the data from a sample FoxInCloud request:
Event: focus ObjAddr: event_scx-pgf-pag1-txt nReq: 3 nKeyCode nButton: -1 nShiftAltCtrl: NaN nXcoord: NaN nYcoord: NaN nRow: NaN nCol: NaN ValueType: string Value: '' lastKey: 73 vpw: 885 vph: 1312 userID: 5AE105A5N reqID: 1808_5FY0VC68D-001 version: 2.28.1-beta.3 sync: false nInet: 0.358 nCli: 0.021
Additional license for extra concurrent users > 10
You can get it here: http://foxincloud.com/pricing.php#pricingFormCaption (form only to get your contact, absolutely no risk of spamming and/or privacy offense)
Here are the figures (**permanent** license, optional 12% yearly for upgrades):
+10: US$ 549 ($55/additional concurrent user)
+100: US$ 2 739 ($27/additional concurrent user)
+250: US$ 4 459 ($17/additional concurrent user)
+1000: US$ 6 869 ($7/additional concurrent user)
ration between concurrent and named users (real-life examples):
ERP including reporting and billing: 10% reporting and billing alone: 2% B2B invoice payment: 5%
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
VisitFoxInCloud Blog http://foxincloud.com/blog/ WatchFoxInCloud Marketing Videos https://www.youtube.com/channel/UCUzzqO5375-fA7dLDds-wOQ WatchFoxInCloud Technical Videos https://www.youtube.com/channel/UCrEohAtbuf3uOXBH2pjp5Vw Stay tuned onFoxInCloud Roadmap http://foxincloud.com/roadmap.php Learnhow to use FoxInCloud http://foxincloud.com/how-to.php DownloadFoxInCloud Adaptation Assistant http://foxincloud.com/download.php for free
Charlie,
Seriously - a Dissertation? But, of course - you Jest! That being said - I get the humor of that comment - as I have used the same comment before.
Will make a Short reply now - and possibly follow-up with a longer reply at a later time.
1st, to be honest - they did NOT mind that I delayed the interview. Understand, I let them know about the death in the family - and thus why I was already down in South Cali. So, I didn't need to add about my not being fully prepared. They just assumed it was most a grief thing. Which, yeah, was part of the crazy things going on in my life lately. Its rough when a close cousin loses his youngest son! So, yeah, UCLA had NO Problems with me delaying interview by 1 day. They actually suggested a delay (which they might have turned into a week long delay) - but, I said no.
In the end, I got to the interview a tad late due to insane LA traffic - and they were VERY Understating!!!
Finally - interview went VERY Well! They seemed to be Very impressed by my code. Actually had Multiple program crashes. One due to a setting in their VFP environ - which I fixed quickly by just changing some settings in the data environ/session. Oddly - they were running VFP 6 and NOT VFP9! Ugh! Then, the 2nd crash was a kinda epic fail - since it seems the ASCAN command had major changes done between V6 & 9! So - to resolve that - we simply ran from my laptop connected to their Big Arse TV screen!
So - all went great. They all seemed truly impressed - and, I did the whole thing in front of 6 people this time around. I've heard of other people in the past having like 4 people in an interview - and grilled by all - and being intimidated by that. But, 6 was better - and it was like I had a Captive audience! As such, I did indeed shine!!!
Final outcome should be this coming Monday! Although will admit - I'm still VERY Wary of trying to survive on such a LOW SALARY!!!
-K-
On 3/20/2019 8:56 AM, Charlie-gm wrote:
My 2 cents (after I wrote this, I realize this is more like a dissertation than a "quick" thought... sorry).
First, grab all those questions Ted mentioned and organize them. You will want to use them - maybe at the end of the interview when they say "do you have any questions for me?" (The "experts" say having active questions about the project/employer puts a big "+" to you with the interviewer). You may know the answers to some already.
I also agree that you should not postpone the interview. Try taking some time today, 15-30 minutes here and there, writing down your prep. Make sure and "write down" things. I bet by the afternoon you'll feel comfortable about the interview. Remember, they ARE LOOKING for help, and you know you can help them.
As for proposing a solution: first, sure, take in what folks on this list say, but evaluate what you think is reasonable and beneficial for YOU. The last thing you want is to recommend something based on what buzzwords you think they want to hear (that they probably don't understand anyway), and then having the nightmare of trying to deliver it. Next, "frame" your recommendation to them - in other words, drop out a few bullet points before going into the recommendation. For example:
- need absolute minimal disruption to users of current application
(emphasize more or less based on what you know about their 'concern' or usage or admiration of the current application)
- want a smooth transition from current developer (assuming
"transition" is definitely in their mind, so word this accordingly - key point, show you view the current developer as a key resource - unless you know they are flat out angry with him in some way - in that case, focus on "functional" transition - aka do not lose functionality)
- want to move out of current environment quickly (I assume the
current environment is something like the app is on individual workstations, connected to a network drive/DB, etc)
- need an expandable/adaptable platform for their business cases (or
functional needs, or some other non-corporate term since this is a university)
- cost is important - initial as well as yearly recurring
- [if you know of a couple other things they have greatly emphasized,
repeat them here - but don't repeat them if they were purely technology statements - e.g. if they've said several times "We need to move this onto .Net" or something like that - don't repeat that here. Those kind of statements show a lack of strategic thinking on their part. But if they've said things like "integrating with our other university systems" - that is a true business/functional goal so it would be good to repeat here (and VFP can do that quite easily - remember, in the end, it's all about the data).
Then this is the kind of outline I'd use
- start off with FoxInCloud - cost is low, extremely low risk of
functional loss, immediate ability to expand functionality, but may need significant server power 2) while maintaining with FoxInCloud, carefully research other platforms for potential code conversion, determine: up front cost, maintenance cost, licensing fees, staffing needs 3) quarterly review research, redirect focus accordingly - it could well be FoxInCloud will be shown the superior long-term solution as well 4) if a rewrite into another platform is chosen, develop deployment plan, incorporating user-noted critical operations (e.g.- "no matter what, make sure I never lose my course material", "make sure I always have that pop-up option copy something to my calendar" , or whatever)
This approach gives them time to carefully evaluate alternatives with extremely low risk of losing functionality or usability, while moving into an easier manageable/deployable domain (aka web/browser - although I have to laugh at that... more info at the end of this message). At the same time, it brings on a valuable resource - YOU - that can help them into a long-term path for this application and maybe others.
Now, if they push about alternative platforms you're aware of:
- C#/.Net - expensive long-term (licensing/MS updates/deprecations),
high risk of long schedule and/or functional/degradation during conversion, but many resources available (at a price) 2) Apache - PHP - Javascript/frameworks - low expense, probable functional degradation/loss - or significant time to replicate, many resources available (but pricey if need to hire consultants, etc) 3) Alpha - somewhat expensive, probable functional degradation/loss (only FoxPro 2.6 table access - advanced VFP database stuff not available), may take significant time to "convert". But BE CAREFUL in talking about this one - it sounds like they have already been exposed to months of "marketing talk" - so you have to be careful about sounding negative on this. You MIGHT mention it is proprietary, so you think it would be a good idea to do independent, detailed technical deep-dives before choosing it. Also, do more research on the Alpha website before the interview - look for comments on the Web. 4) Servoy (you probably should do a quick look at their website, etc. I looked at them but decided it would be a huge rewrite of my code base, etc - not to mention expensive the last time I checked) 5) X# is a possibility, and may be a low-risk translation when VFP syntax becomes available, but need to be wary of potential costs (.Net? - aka, look at what Oracle recently did with Java licensing...)
One thing that may come up is security. If you go with the FoxInCloud as the starting point, talk to Therry - get some points about how that platform addresses security. If you don't feel comfortable talking about HTTPS, TLS2.0, certificate management, man-in-the-middle attacks, blah blah blah, don't bring it up yourself (sorry about the buzzword drops). They may not even be aware of the massive attack vectors they are opening by moving an application to the "web" - but at least be prepared to give a few points about your primary proposal if they ask about it.
So, again, with the above alternatives, you need to look at this from YOUR angle. But let me try to put your mind at ease. None... and I mean ABSOLUTELY NONE, of all the latest fads of languages, platforms, blah blah blah, are conceptually much different than what you already know about developing applications. The challenge is the massively different SYNTAX and TERMINOLOGY they use (as time goes on I'm becoming more convinced that platforms that created "new" syntax/terminology did so for marketing, and not technical, advancement). JVM? -> VFP runtime files. Client-server? -> buffered data (yes, much more, but conceptually think extra steps to "commit" data, etc). APIs? -> object methods (but the object could be MASSIVE, a whole application unto itself). I am over-simplifying to a degree, but if you have developed the ability to solve complicated problems in VFP, then you have the ability to translate and internalize all the latest and greatest buzzword platforms so that you could use them yourself. Note: if you go that route, you will likely be frustrated and amazed at the "backward leaps" some of these "advanced technologies" are as compared to VFP - hahahahaha.
Sorry, this is too long already, but let me add a couple things. With the FoxInCloud, you may want to talk with Therry directly about costs. I think the base license is only 10 concurrent users. That may not be adequate for how the current application is used. I could not find the additional license fees on their site, so I'd say talk to him privately. Just make sure you have some good estimates you can put in front of them.
Now look at the above and make it all YOUR OWN. If you don't like something or are uncomfortable with it, toss it out. If you know of something else that interests you, add it. At the end of the day this is about matching you to a job. The key point is if you feel you would be willing to dip into other technologies/platforms (albeit, generally inferior ones), then you want to be clear you have that ability. And that will require a little research - hopefully the above gives you some starting points.
If I recall, this interview may be more of a "code test" regarding VFP. If so, that's great, you have no worries. Then, if they start talking about the future and what path you would take, just be confident in what you are proposing, and know WHY you are proposing it. They need help, you can readily provide it.
I'll end by briefly talking about 2 things: 1) I have NEVER seen a "good" rewrite of any of my VFP applications (I've seen it attempted 5 times). 3 of the 5 ended with a loss of about 50% functionality - about 400% higher maintenance costs (aka licensing, personnel), and limited (or expensive) expandability - but hey, it runs in a web browser (the client was very upset to say the least). In another, a gov agency was providing software to help companies "file" data -Â the gov decided it did not want to distribute VFP apps and so tried to convert to a web-based .Net thing. After about 18 months (I think, I didn't stay there until the end), they gave up the conversion effort and decided to just publish a "data format" - so the companies had to go pay for their own software development to create the filing (I thought about tapping into that, but the insanity at the gov organization and the filing companies really put me off - and I had other cool things sitting in front of me <g>). For the last one, the conversion went on for about 2 years I think (not sure I wasn't there), but apparently they gave up on that too. It turns out they are still using my VFP application (actually several of them on the same "specialized framework"). This is 20 YEARS LATER! ROFLMAO - thinking back to some of the "discussions" I had with MS .Net certified experts, how they told me VFP is not a viable long-term platform, it could not support complicated business needs.... hahahahaha... all the apps those guys worked on... ALL OF THEM - have gone the way of the dodo bird - and those VFP apps are chugging along.
Sorry... not brief at all... but number 2) is, guess what.... Rich Client Applications have won the war. Of course, most "web vendors" are trying to hide that fact. But if you look at the "advancements" in Javascript - they are all about client-side processing. They recently put things in like "service workers", and "indexed database" (different term? - can't remember), local cache management... Oh... my.... god. I recently finished a "nanodegree" in front-end web development and when we got to those "advancements" I really nearly fell out of my chair laughing. All these things ALL OF THEM I did in VFP like 20 years ago (server application - distributed VFP apps - with West-wind as the 'linking' piece). And the claims about web applications being easier to deploy and easier to maintain.... oops... I really almost fell out of my chair laughing again. In that course, I spent maybe 40% of the time "debugging" the freakin' framework they wanted us to use (Angular, Vue, React, Ember, Jasmine, blah blah blah). But to be fair, some of those things are getting close to the stability and reliability that VFP has. I heard recently (on this list?) that maybe Python and other languages are going to be "natively" available in browsers soon. I sure hope so. Javascript is interesting, but it is not object-oriented, and it's been "functionally patching" itself like crazy and thus has a lot of quirks that get in the way (and create maintenance nightmares).
Ok, those last 2 paragraphs were a digression. I was trying to give you confidence that you can indeed pick up any of the advanced--- oops, threw up in my mouth a little... So let me say, pick up any of the "newer" platforms. For me, the best way to learn them is not necessarily "courses" (nor "certification programs"), but to build something "real" with them. If you land this job, you can help the employer in the near-term and then learn those other platforms and help them pick the "right" one (instead of the best-marketed one). I would also say, do not make the interview about a defense of VFP - instead, make it about you being a resource that can reliably meet their near-term needs as well as their long-term needs.
Wishing you the best of luck.
HTH, -Charlie
On 3/20/2019 7:28 AM, Ted Roche wrote:
On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX vrfx@optonline.net wrote
The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently,
I'm sympathetic to your situation, but you don't want the wrong interviewer hearing that you're too busy babysitting parrots to interview for a job. That's harsh, and you might not want to work for such a jerk, but you don't want to raise red flags, or even questions, during the interview process, OTOH, you don't want to work for jerks, either. OTOOH, they're paying peanuts and desperate for Fox expertise. Your call,
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
A 30 year's experienced app developer may have some real legacy stuff in their app, and conversion can be a large undertaking. Along with a parallel investigation of what the client needs the app to do is an audit of what the application already does, Whil's Developer Guide went into this in some detail, and I presented a series of lectures with checklists and software for an initial audit.
So, the answer to the question on what they should do is to ask what they want, and what they have? How many lines of code? How many tables? How many fields? Where's the ERD? How many output documents, reports? Where does the data come from? Where does it go? What's the IT infrastructure? What kind of data servers do they support? What kind of maintenance windows are allowed? Where are the users? How do they access the data: PCs, laptops on the road, tablets, phones, embedded in other services? How responsive does the app have to be? What happens in case of failure? What's the backup strategy? What's the disaster recovery plan?
I suspect its also because the 1 and only programmer there, who's
been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition!
It's likely your job is to learn everything the old Obi-Wan knows and become the new master. Realistically (and perhaps this isn't an interview topic), you'll keep the old app running for some time as you transition the data model, the business model, the services model and the interface(s) to the new platform.
They are asking me to propose what I think is the best option.
When a consultant tells me they have the solution to all of my business needs by replacing a 30-year-old system with whatever they are selling, on the first meeting, sight-unseen, I would be rightfully skeptical.
The right answer is that they need to let you learn the app and research the right solution. If you can convince them you are knowlegeable about what is available, and what the issues are that need to be addressed in a migration, then they should hire you to do your job.
There are a lot of good resources out there, like this list, the FoxWiki, books, whitepapers, but you will need to do the footwork. See if you can convince them to pay you to do that.
[excessive quoting removed by server]
Good to hear how it went.
On Wed, Mar 27, 2019 at 10:07 PM Kurt at VR-FX vrfx@optonline.net wrote:
Charlie,
Seriously - a Dissertation? But, of course - you Jest! That being said - I get the humor of that comment - as I have used the same comment before.
Will make a Short reply now - and possibly follow-up with a longer reply at a later time.
1st, to be honest - they did NOT mind that I delayed the interview. Understand, I let them know about the death in the family - and thus why I was already down in South Cali. So, I didn't need to add about my not being fully prepared. They just assumed it was most a grief thing. Which, yeah, was part of the crazy things going on in my life lately. Its rough when a close cousin loses his youngest son! So, yeah, UCLA had NO Problems with me delaying interview by 1 day. They actually suggested a delay (which they might have turned into a week long delay) - but, I said no.
In the end, I got to the interview a tad late due to insane LA traffic - and they were VERY Understating!!!
Finally - interview went VERY Well! They seemed to be Very impressed by my code. Actually had Multiple program crashes. One due to a setting in their VFP environ - which I fixed quickly by just changing some settings in the data environ/session. Oddly - they were running VFP 6 and NOT VFP9! Ugh! Then, the 2nd crash was a kinda epic fail - since it seems the ASCAN command had major changes done between V6 & 9! So - to resolve that - we simply ran from my laptop connected to their Big Arse TV screen!
So - all went great. They all seemed truly impressed - and, I did the whole thing in front of 6 people this time around. I've heard of other people in the past having like 4 people in an interview - and grilled by all - and being intimidated by that. But, 6 was better - and it was like I had a Captive audience! As such, I did indeed shine!!!
Final outcome should be this coming Monday! Although will admit - I'm still VERY Wary of trying to survive on such a LOW SALARY!!!
-K-
On 3/20/2019 8:56 AM, Charlie-gm wrote:
My 2 cents (after I wrote this, I realize this is more like a dissertation than a "quick" thought... sorry).
First, grab all those questions Ted mentioned and organize them. You will want to use them - maybe at the end of the interview when they say "do you have any questions for me?" (The "experts" say having active questions about the project/employer puts a big "+" to you with the interviewer). You may know the answers to some already.
I also agree that you should not postpone the interview. Try taking some time today, 15-30 minutes here and there, writing down your prep. Make sure and "write down" things. I bet by the afternoon you'll feel comfortable about the interview. Remember, they ARE LOOKING for help, and you know you can help them.
As for proposing a solution: first, sure, take in what folks on this list say, but evaluate what you think is reasonable and beneficial for YOU. The last thing you want is to recommend something based on what buzzwords you think they want to hear (that they probably don't understand anyway), and then having the nightmare of trying to deliver it. Next, "frame" your recommendation to them - in other words, drop out a few bullet points before going into the recommendation. For example:
- need absolute minimal disruption to users of current application
(emphasize more or less based on what you know about their 'concern' or usage or admiration of the current application)
- want a smooth transition from current developer (assuming
"transition" is definitely in their mind, so word this accordingly - key point, show you view the current developer as a key resource - unless you know they are flat out angry with him in some way - in that case, focus on "functional" transition - aka do not lose functionality)
- want to move out of current environment quickly (I assume the
current environment is something like the app is on individual workstations, connected to a network drive/DB, etc)
- need an expandable/adaptable platform for their business cases (or
functional needs, or some other non-corporate term since this is a university)
- cost is important - initial as well as yearly recurring
- [if you know of a couple other things they have greatly emphasized,
repeat them here - but don't repeat them if they were purely technology statements - e.g. if they've said several times "We need to move this onto .Net" or something like that - don't repeat that here. Those kind of statements show a lack of strategic thinking on their part. But if they've said things like "integrating with our other university systems" - that is a true business/functional goal so it would be good to repeat here (and VFP can do that quite easily - remember, in the end, it's all about the data).
Then this is the kind of outline I'd use
- start off with FoxInCloud - cost is low, extremely low risk of
functional loss, immediate ability to expand functionality, but may need significant server power 2) while maintaining with FoxInCloud, carefully research other platforms for potential code conversion, determine: up front cost, maintenance cost, licensing fees, staffing needs 3) quarterly review research, redirect focus accordingly - it could well be FoxInCloud will be shown the superior long-term solution as well 4) if a rewrite into another platform is chosen, develop deployment plan, incorporating user-noted critical operations (e.g.- "no matter what, make sure I never lose my course material", "make sure I always have that pop-up option copy something to my calendar" , or whatever)
This approach gives them time to carefully evaluate alternatives with extremely low risk of losing functionality or usability, while moving into an easier manageable/deployable domain (aka web/browser - although I have to laugh at that... more info at the end of this message). At the same time, it brings on a valuable resource - YOU - that can help them into a long-term path for this application and maybe others.
Now, if they push about alternative platforms you're aware of:
- C#/.Net - expensive long-term (licensing/MS updates/deprecations),
high risk of long schedule and/or functional/degradation during conversion, but many resources available (at a price) 2) Apache - PHP - Javascript/frameworks - low expense, probable functional degradation/loss - or significant time to replicate, many resources available (but pricey if need to hire consultants, etc) 3) Alpha - somewhat expensive, probable functional degradation/loss (only FoxPro 2.6 table access - advanced VFP database stuff not available), may take significant time to "convert". But BE CAREFUL in talking about this one - it sounds like they have already been exposed to months of "marketing talk" - so you have to be careful about sounding negative on this. You MIGHT mention it is proprietary, so you think it would be a good idea to do independent, detailed technical deep-dives before choosing it. Also, do more research on the Alpha website before the interview - look for comments on the Web. 4) Servoy (you probably should do a quick look at their website, etc. I looked at them but decided it would be a huge rewrite of my code base, etc - not to mention expensive the last time I checked) 5) X# is a possibility, and may be a low-risk translation when VFP syntax becomes available, but need to be wary of potential costs (.Net? - aka, look at what Oracle recently did with Java licensing...)
One thing that may come up is security. If you go with the FoxInCloud as the starting point, talk to Therry - get some points about how that platform addresses security. If you don't feel comfortable talking about HTTPS, TLS2.0, certificate management, man-in-the-middle attacks, blah blah blah, don't bring it up yourself (sorry about the buzzword drops). They may not even be aware of the massive attack vectors they are opening by moving an application to the "web" - but at least be prepared to give a few points about your primary proposal if they ask about it.
So, again, with the above alternatives, you need to look at this from YOUR angle. But let me try to put your mind at ease. None... and I mean ABSOLUTELY NONE, of all the latest fads of languages, platforms, blah blah blah, are conceptually much different than what you already know about developing applications. The challenge is the massively different SYNTAX and TERMINOLOGY they use (as time goes on I'm becoming more convinced that platforms that created "new" syntax/terminology did so for marketing, and not technical, advancement). JVM? -> VFP runtime files. Client-server? -> buffered data (yes, much more, but conceptually think extra steps to "commit" data, etc). APIs? -> object methods (but the object could be MASSIVE, a whole application unto itself). I am over-simplifying to a degree, but if you have developed the ability to solve complicated problems in VFP, then you have the ability to translate and internalize all the latest and greatest buzzword platforms so that you could use them yourself. Note: if you go that route, you will likely be frustrated and amazed at the "backward leaps" some of these "advanced technologies" are as compared to VFP - hahahahaha.
Sorry, this is too long already, but let me add a couple things. With the FoxInCloud, you may want to talk with Therry directly about costs. I think the base license is only 10 concurrent users. That may not be adequate for how the current application is used. I could not find the additional license fees on their site, so I'd say talk to him privately. Just make sure you have some good estimates you can put in front of them.
Now look at the above and make it all YOUR OWN. If you don't like something or are uncomfortable with it, toss it out. If you know of something else that interests you, add it. At the end of the day this is about matching you to a job. The key point is if you feel you would be willing to dip into other technologies/platforms (albeit, generally inferior ones), then you want to be clear you have that ability. And that will require a little research - hopefully the above gives you some starting points.
If I recall, this interview may be more of a "code test" regarding VFP. If so, that's great, you have no worries. Then, if they start talking about the future and what path you would take, just be confident in what you are proposing, and know WHY you are proposing it. They need help, you can readily provide it.
I'll end by briefly talking about 2 things: 1) I have NEVER seen a "good" rewrite of any of my VFP applications (I've seen it attempted 5 times). 3 of the 5 ended with a loss of about 50% functionality - about 400% higher maintenance costs (aka licensing, personnel), and limited (or expensive) expandability - but hey, it runs in a web browser (the client was very upset to say the least). In another, a gov agency was providing software to help companies "file" data -Â the gov decided it did not want to distribute VFP apps and so tried to convert to a web-based .Net thing. After about 18 months (I think, I didn't stay there until the end), they gave up the conversion effort and decided to just publish a "data format" - so the companies had to go pay for their own software development to create the filing (I thought about tapping into that, but the insanity at the gov organization and the filing companies really put me off - and I had other cool things sitting in front of me <g>). For the last one, the conversion went on for about 2 years I think (not sure I wasn't there), but apparently they gave up on that too. It turns out they are still using my VFP application (actually several of them on the same "specialized framework"). This is 20 YEARS LATER! ROFLMAO - thinking back to some of the "discussions" I had with MS .Net certified experts, how they told me VFP is not a viable long-term platform, it could not support complicated business needs.... hahahahaha... all the apps those guys worked on... ALL OF THEM - have gone the way of the dodo bird - and those VFP apps are chugging along.
Sorry... not brief at all... but number 2) is, guess what.... Rich Client Applications have won the war. Of course, most "web vendors" are trying to hide that fact. But if you look at the "advancements" in Javascript - they are all about client-side processing. They recently put things in like "service workers", and "indexed database" (different term? - can't remember), local cache management... Oh... my.... god. I recently finished a "nanodegree" in front-end web development and when we got to those "advancements" I really nearly fell out of my chair laughing. All these things ALL OF THEM I did in VFP like 20 years ago (server application - distributed VFP apps - with West-wind as the 'linking' piece). And the claims about web applications being easier to deploy and easier to maintain.... oops... I really almost fell out of my chair laughing again. In that course, I spent maybe 40% of the time "debugging" the freakin' framework they wanted us to use (Angular, Vue, React, Ember, Jasmine, blah blah blah). But to be fair, some of those things are getting close to the stability and reliability that VFP has. I heard recently (on this list?) that maybe Python and other languages are going to be "natively" available in browsers soon. I sure hope so. Javascript is interesting, but it is not object-oriented, and it's been "functionally patching" itself like crazy and thus has a lot of quirks that get in the way (and create maintenance nightmares).
Ok, those last 2 paragraphs were a digression. I was trying to give you confidence that you can indeed pick up any of the advanced--- oops, threw up in my mouth a little... So let me say, pick up any of the "newer" platforms. For me, the best way to learn them is not necessarily "courses" (nor "certification programs"), but to build something "real" with them. If you land this job, you can help the employer in the near-term and then learn those other platforms and help them pick the "right" one (instead of the best-marketed one). I would also say, do not make the interview about a defense of VFP - instead, make it about you being a resource that can reliably meet their near-term needs as well as their long-term needs.
Wishing you the best of luck.
HTH, -Charlie
On 3/20/2019 7:28 AM, Ted Roche wrote:
On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX vrfx@optonline.net
wrote
The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently,
I'm sympathetic to your situation, but you don't want the wrong interviewer hearing that you're too busy babysitting parrots to interview for a job. That's harsh, and you might not want to work for such a jerk, but you don't want to raise red flags, or even questions, during the interview process, OTOH, you don't want to work for jerks, either. OTOOH, they're paying peanuts and desperate for Fox expertise. Your call,
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
A 30 year's experienced app developer may have some real legacy stuff in their app, and conversion can be a large undertaking. Along with a parallel investigation of what the client needs the app to do is an audit of what the application already does, Whil's Developer Guide went into this in some detail, and I presented a series of lectures with checklists and software for an initial audit.
So, the answer to the question on what they should do is to ask what they want, and what they have? How many lines of code? How many tables? How many fields? Where's the ERD? How many output documents, reports? Where does the data come from? Where does it go? What's the IT infrastructure? What kind of data servers do they support? What kind of maintenance windows are allowed? Where are the users? How do they access the data: PCs, laptops on the road, tablets, phones, embedded in other services? How responsive does the app have to be? What happens in case of failure? What's the backup strategy? What's the disaster recovery plan?
I suspect its also because the 1 and only programmer there, who's
been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition!
It's likely your job is to learn everything the old Obi-Wan knows and become the new master. Realistically (and perhaps this isn't an interview topic), you'll keep the old app running for some time as you transition the data model, the business model, the services model and the interface(s) to the new platform.
They are asking me to propose what I think is the best option.
When a consultant tells me they have the solution to all of my business needs by replacing a 30-year-old system with whatever they are selling, on the first meeting, sight-unseen, I would be rightfully skeptical.
The right answer is that they need to let you learn the app and research the right solution. If you can convince them you are knowlegeable about what is available, and what the issues are that need to be addressed in a migration, then they should hire you to do your job.
There are a lot of good resources out there, like this list, the FoxWiki, books, whitepapers, but you will need to do the footwork. See if you can convince them to pay you to do that.
[excessive quoting removed by server]
This sounds like a set-up type of question.
I would go in with the knowledge that they want to step away from VFP. I wouldn't give them a "with what" before you had the time to learn what it does as well as what the owners want it to do. This position is in academia and they have an attitude about how things should go. Are they looking to go totally open source and do they want to operate in the cloud?
My take on this is that they don't a rats ass if the program is in another version of X-Base, they just want it to work.
There should be no problem for making the interview.
On Wed, Mar 20, 2019 at 12:45 AM Kurt at VR-FX vrfx@optonline.net wrote:
Hello there folks, I'm looking to get some feedback from the hive mind of this group. And, I will admit, I'm doing this kind of last minute. Too many things going on lately, and I have not had a chance to do my true due diligence! Such as thorough research via prior postings in this forum.
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently, that's the reason I'm going down to LA for an in-person interview, since the last interview I did via Skype. It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP. I suspect its also because the 1 and only programmer there, who's been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition! They are asking me to propose what I think is the best option. They have mentioned several options such as Fox-in-Cloud, the Alpha software, and even Servoy. They did not bring up things like Lianja, XoJo, or X# the open source X-base language.
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
They also told me that they have already been working with Alpha SW - and in discussions with them for several months. Which makes me think they are already leaning towards Alpha. A quick review of old postings in this forum did not show a lot of discussion or users of Alpha. It would really be great to hear from some Alpha users!
Anyway - any and all input would be greatly appreciated. I've seen Numerous discussions about a number of these technologies here in the forum over the years. But, honestly - I never truly got involved with any of them - until NOW!
Regards, Kurt
[excessive quoting removed by server]
On 03/20/19 1:45 AM, Kurt at VR-FX wrote:
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
I don't actually use Fox-in-Cloud, but doesn't the developer often post in here? Or you could ask them directly on their website?
Good luck! Knock 'em dead!
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Yes - indeed he does - its one of the reasons that I kinda directed my questions to him and pointed out his name. And, as I knew he would - he was one of the first to respond!
Thank you Vince & Thierry for your replies. As for the other replies - WOW - am going to reply again momentarily - after I get some BFast!
-K-
On 3/20/2019 7:30 AM, Vince Teachout wrote:
On 03/20/19 1:45 AM, Kurt at VR-FX wrote:
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
I don't actually use Fox-in-Cloud, but doesn't the developer often post in here? Or you could ask them directly on their website?
Good luck! Knock 'em dead!
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Wed, Mar 20, 2019 at 10:50 AM Kurt at VR-FX vrfx@optonline.net wrote:
WOW - am going to reply again momentarily - after I get some BFast!
I'm pretty sure FoxPro is up to JFast!
(Inside joke for the old, old, OLD Foxers!)
lol. Takes me back.
On Wed, Mar 20, 2019 at 3:57 PM Ted Roche tedroche@gmail.com wrote:
On Wed, Mar 20, 2019 at 10:50 AM Kurt at VR-FX vrfx@optonline.net wrote:
WOW - am going to reply again momentarily - after I get some BFast!
I'm pretty sure FoxPro is up to JFast!
(Inside joke for the old, old, OLD Foxers!)
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
NICE!
:-)
On 3/20/2019 7:56 AM, Ted Roche wrote:
On Wed, Mar 20, 2019 at 10:50 AM Kurt at VR-FX vrfx@optonline.net wrote:
WOW - am going to reply again momentarily - after I get some BFast!
I'm pretty sure FoxPro is up to JFast!
(Inside joke for the old, old, OLD Foxers!)
Hi Kurt,
Sorry for not responding earlier. But here goes. I am a X# user. Yes be careful of them using the interview as cheap "consultation"...
On 2019/03/20 07:45, Kurt at VR-FX wrote:
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up. They did not bring up things like Lianja, XoJo, or X# the open source X-base language. There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
FoxPro experts are already working behind the scene in a project I initiated after identifying Fox developers I believe is suitable to demystify the VFP IDE repo and reproduce it in a X# readable text format. From this format we busy to recreate it with a VFPTransporter, similar to the VOTransporter that was created to move Visual Objects code to X#, into a Visual Studio solution and XIDE repo. We think it might be possible to convert the Fox Screen designer straight into a WinForm, Menu to MenuStrip, etc. Fox command translations will be a combination of the X# DevTeam adding support for these unrecognized commands in X#, #commands in a (VFP.xh) for the X# pre-proccessor to translate, or hard code Translaters in the Transporter for difficult pieces of VFP code. We quite excited, VFP users assisting and I, as part of this community initiative joint venture between VFP and X#, probably a first in the XBase world. We hope to have something ready that can be demonstrated at the French Fox conference atoutfox in May and progress at Fox conferences later in the year. If we achieve the goal, you obviously need to learn the .NET way of doing stuff and get an understanding of the X# syntax to open up the world of .NET consumption, it is huge. Any code written in a .NET language you can use as if written in X#. Have a class in a c#/VB.NET assembly, no sweat just add a reference and use it. Want to add new features to this class just create a new class inheriting from the c# class. Done, use it in your code.
Watch this space!
Johan Nel Friend of X# (FOX) member.
Johan Will you post a confirmation when you Will show a demo at the next aToutFox conference here? Or should I monitor aToutFrance? Regards Koen
Op wo 20 mrt. 2019 om 14:16 schreef Johan Nel johan.nel@xsinet.co.za
Hi Kurt,
Sorry for not responding earlier. But here goes. I am a X# user. Yes be careful of them using the interview as cheap "consultation"...
On 2019/03/20 07:45, Kurt at VR-FX wrote:
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up. They did not bring up things like Lianja, XoJo, or X# the open source X-base language. There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
FoxPro experts are already working behind the scene in a project I initiated after identifying Fox developers I believe is suitable to demystify the VFP IDE repo and reproduce it in a X# readable text format. From this format we busy to recreate it with a VFPTransporter, similar to the VOTransporter that was created to move Visual Objects code to X#, into a Visual Studio solution and XIDE repo. We think it might be possible to convert the Fox Screen designer straight into a WinForm, Menu to MenuStrip, etc. Fox command translations will be a combination of the X# DevTeam adding support for these unrecognized commands in X#, #commands in a (VFP.xh) for the X# pre-proccessor to translate, or hard code Translaters in the Transporter for difficult pieces of VFP code. We quite excited, VFP users assisting and I, as part of this community initiative joint venture between VFP and X#, probably a first in the XBase world. We hope to have something ready that can be demonstrated at the French Fox conference atoutfox in May and progress at Fox conferences later in the year. If we achieve the goal, you obviously need to learn the .NET way of doing stuff and get an understanding of the X# syntax to open up the world of .NET consumption, it is huge. Any code written in a .NET language you can use as if written in X#. Have a class in a c#/VB.NET assembly, no sweat just add a reference and use it. Want to add new features to this class just create a new class inheriting from the c# class. Done, use it in your code.
Watch this space!
Johan Nel Friend of X# (FOX) member.
[excessive quoting removed by server]
Another interesting thing to follow at SWFox 2019 was the X#.Net open source language, and how they are making good progress with supporting the FoxPro language in X#.Net
Eric Selje presented a session on it, and two people from the X# Developer Team flew over (from the Netherlands, and France) to have a vendor booth and sessions.
I recorded a video of the X# Dev Team presentation (from my iPhone) and posted it on YouTube here:
X# web site has download link to the code presented at the SWFox vendor session:
https://www.xsharp.info/articles/presentations-and-examples-from-sw-fox
- Matt Slay
On 10/30/2019 1:38 PM, Eric Selje wrote:
Great recap of VFP Advanced, Richard. And yes you did great Tracy! Great to see you there, and would love to see more next year.
Eric
On Wed, Oct 30, 2019 at 10:43 AM Richard Kaye rkaye@invaluable.com wrote:
And further to that, a big, big shout-out to Doug, Rick & Tamar, and all the speakers for making this happen. The amount of work that goes into pulling off something like this is a labor of love, and Geek Gatherings deserves all the love they get in return.
Here are a few of my highlights:
In a session on internationalization, Cathy Poutney announced that Steven Black's INTL Toolkit is now open source. If you need a framework that handles translations for different languages or even industries, head over to Github and download it.
The aforementioned Cathy Poutney did a session on, what else, extending the reporting engine with a framework she's calling fxReports. This is (or will be soon) available as an open source project in VFPx.
Eric Selje did a very interesting session called "VFP Advanced: Is this the next version of Visual Foxpro?". Basically a rocket scientist lone developer in China has reverse engineered VFP, and patched at least 96 bugs (to date) in our favorite tool and its runtimes. All you need to try this out is a licensed copy of VFP9 SP2, hotfix3, and you can install this side by side. He has also released a 64 bit version. There are pros and cons to using the 64 git version. For example, he has not breached the 2GB file size limitation. OTOH it uses newer supported versions of the C++runtime (10.1, I believe) instead of the apparently out of support 7.1 library that VFP is written in.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Richard Kaye Sent: Wednesday, October 30, 2019 12:44 PM To: profoxtech@leafe.com Subject: RE: SWFox 2019 recap
I was not a presenter, like Tracy <vbg>, but I also had a great time at SWFox. It's a joy to spend time with one's peers learning new (and sometimes old) things, as well as meeting in person with both old and new friends. I would also encourage anyone on this list who still works with the Fox to consider attending next year's conference, which is scheduled for November 12-15, 2020.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Wednesday, October 30, 2019 12:38 PM To: profoxtech@leafe.com Subject: SWFox 2019 recap
I am back to calm after the first day back to work. I had a great time at the conference and hope to stay connected with those I met. I answered an email this morning and thought about the conversation I had with Richard Kaye. <grin>
Good conversations, good information, and a fun time.
I hear I did well as my first time speaking at the conference.
Maybe we can get more ProFoxers to go in 2020.
See you around! Tracy
[excessive quoting removed by server]
Yes, and from report back from Tore Bleken, who attended the post-conference X# training, 33 attendees (36 started, but had to leave early), which is 50% of registrations (67). Makes for quite a buzz in the way forward for VFP developers. The DevTeam also listens and I am sure what was discussed at the session will somehow find its way into the VFP language syntax support in X#.
The X# user base is definitely looking forward to accept our "long lost" cousins into the world of XBase.NET!!!
On 2019/10/30 20:53, Matt Slay wrote:
Another interesting thing to follow at SWFox 2019 was the X#.Net open source language, and how they are making good progress with supporting the FoxPro language in X#.Net
Eric Selje presented a session on it, and two people from the X# Developer Team flew over (from the Netherlands, and France) to have a vendor booth and sessions.
I recorded a video of the X# Dev Team presentation (from my iPhone) and posted it on YouTube here:
X# web site has download link to the code presented at the SWFox vendor session:
https://www.xsharp.info/articles/presentations-and-examples-from-sw-fox
- Matt Slay
On 10/30/2019 1:38 PM, Eric Selje wrote:
Great recap of VFP Advanced, Richard. And yes you did great Tracy! Great to see you there, and would love to see more next year.
Eric
On Wed, Oct 30, 2019 at 10:43 AM Richard Kaye rkaye@invaluable.com wrote:
And further to that, a big, big shout-out to Doug, Rick & Tamar, and all the speakers for making this happen. The amount of work that goes into pulling off something like this is a labor of love, and Geek Gatherings deserves all the love they get in return.
Here are a few of my highlights:
In a session on internationalization, Cathy Poutney announced that Steven Black's INTL Toolkit is now open source. If you need a framework that handles translations for different languages or even industries, head over to Github and download it.
The aforementioned Cathy Poutney did a session on, what else, extending the reporting engine with a framework she's calling fxReports. This is (or will be soon) available as an open source project in VFPx.
Eric Selje did a very interesting session called "VFP Advanced: Is this the next version of Visual Foxpro?". Basically a rocket scientist lone developer in China has reverse engineered VFP, and patched at least 96 bugs (to date) in our favorite tool and its runtimes. All you need to try this out is a licensed copy of VFP9 SP2, hotfix3, and you can install this side by side. He has also released a 64 bit version. There are pros and cons to using the 64 git version. For example, he has not breached the 2GB file size limitation. OTOH it uses newer supported versions of the C++runtime (10.1, I believe) instead of the apparently out of support 7.1 library that VFP is written in.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Richard Kaye Sent: Wednesday, October 30, 2019 12:44 PM To: profoxtech@leafe.com Subject: RE: SWFox 2019 recap
I was not a presenter, like Tracy <vbg>, but I also had a great time at SWFox. It's a joy to spend time with one's peers learning new (and sometimes old) things, as well as meeting in person with both old and new friends. I would also encourage anyone on this list who still works with the Fox to consider attending next year's conference, which is scheduled for November 12-15, 2020.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Wednesday, October 30, 2019 12:38 PM To: profoxtech@leafe.com Subject: SWFox 2019 recap
I am back to calm after the first day back to work. I had a great time at the conference and hope to stay connected with those I met. I answered an email this morning and thought about the conversation I had with Richard Kaye. <grin>
Good conversations, good information, and a fun time.
I hear I did well as my first time speaking at the conference.
Maybe we can get more ProFoxers to go in 2020.
See you around! Tracy
[excessive quoting removed by server]
Yes, it was a beautiful afternoon and we'd all been cooped up inside for 3 days and yet still almost half of us decided to stay for another 90 minutes to learn more about this exciting project.
Cecil has started an X# Group on LinkedIn: https://www.linkedin.com/groups/13754150/
One thing many folks have asked for is a complete burndown chart of existing VFP commands to be implemented. I'm not sure 100% compatibility will ever happen, and many many things are easily accomplished in .NET already with very similar commands. Robert's son has begun that list though and I believe Matt Slay is working on making it publicly available.
Eric
On Wed, Oct 30, 2019 at 5:56 PM Johan Nel johan.nel@xsinet.co.za wrote:
Yes, and from report back from Tore Bleken, who attended the post-conference X# training, 33 attendees (36 started, but had to leave early), which is 50% of registrations (67). Makes for quite a buzz in the way forward for VFP developers. The DevTeam also listens and I am sure what was discussed at the session will somehow find its way into the VFP language syntax support in X#.
The X# user base is definitely looking forward to accept our "long lost" cousins into the world of XBase.NET!!!
On 2019/10/30 20:53, Matt Slay wrote:
Another interesting thing to follow at SWFox 2019 was the X#.Net open source language, and how they are making good progress with supporting the FoxPro language in X#.Net
Eric Selje presented a session on it, and two people from the X# Developer Team flew over (from the Netherlands, and France) to have a vendor booth and sessions.
I recorded a video of the X# Dev Team presentation (from my iPhone) and posted it on YouTube here:
https://youtu.be/wA61SryiMlkX# web site has download link to the code presented at the SWFox vendor session:
https://www.xsharp.info/articles/presentations-and-examples-from-sw-fox
- Matt Slay
On 10/30/2019 1:38 PM, Eric Selje wrote:
Great recap of VFP Advanced, Richard. And yes you did great Tracy! Great to see you there, and would love to see more next year.
Eric
On Wed, Oct 30, 2019 at 10:43 AM Richard Kaye rkaye@invaluable.com wrote:
And further to that, a big, big shout-out to Doug, Rick & Tamar, and all the speakers for making this happen. The amount of work that goes into pulling off something like this is a labor of love, and Geek Gatherings deserves all the love they get in return.
Here are a few of my highlights:
In a session on internationalization, Cathy Poutney announced that Steven Black's INTL Toolkit is now open source. If you need a framework that handles translations for different languages or even industries, head over to Github and download it.
The aforementioned Cathy Poutney did a session on, what else, extending the reporting engine with a framework she's calling fxReports. This is (or will be soon) available as an open source project in VFPx.
Eric Selje did a very interesting session called "VFP Advanced: Is this the next version of Visual Foxpro?". Basically a rocket scientist lone developer in China has reverse engineered VFP, and patched at least 96 bugs (to date) in our favorite tool and its runtimes. All you need to try this out is a licensed copy of VFP9 SP2, hotfix3, and you can install this side by side. He has also released a 64 bit version. There are pros and cons to using the 64 git version. For example, he has not breached the 2GB file size limitation. OTOH it uses newer supported versions of the C++runtime (10.1, I believe) instead of the apparently out of support 7.1 library that VFP is written in.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Richard Kaye Sent: Wednesday, October 30, 2019 12:44 PM To: profoxtech@leafe.com Subject: RE: SWFox 2019 recap
I was not a presenter, like Tracy <vbg>, but I also had a great time at SWFox. It's a joy to spend time with one's peers learning new (and sometimes old) things, as well as meeting in person with both old and new friends. I would also encourage anyone on this list who still works with the Fox to consider attending next year's conference, which is scheduled for November 12-15, 2020.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Wednesday, October 30, 2019 12:38 PM To: profoxtech@leafe.com Subject: SWFox 2019 recap
I am back to calm after the first day back to work. I had a great time at the conference and hope to stay connected with those I met. I answered an email this morning and thought about the conversation I had with Richard Kaye. <grin>
Good conversations, good information, and a fun time.
I hear I did well as my first time speaking at the conference.
Maybe we can get more ProFoxers to go in 2020.
See you around! Tracy
[excessive quoting removed by server]
Kurt,
As with some of the others, my thought is that you can't realistically recommend some other product until you are much more familiar with what parts they currently use and how they use them. And what they would hope to accomplish with those once moved to the new environment. There are lots of tools out there and no way to know which is best until you understand what they have.
Also, X# has a considerable amount of interest, simply because it will (in theory) allow you to run the current VFP code as well as add new features in C#, F#, VB. But it's all a guessing game until they are able to release something.
It may also be that you are the only candidate they can find. And you do hang out with some of the best names in the industry (heck, if the current developer has any VFP books, chances are they were written by folks here - who might even give you a recommendation.)
Anyway, I wish you the best,
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Kurt at VR-FX Sent: Tuesday, March 19, 2019 10:45 PM To: ProFox Email List Subject: A FoxPro Transition @ UCLA...
Hello there folks, I'm looking to get some feedback from the hive mind of this group. And, I will admit, I'm doing this kind of last minute. Too many things going on lately, and I have not had a chance to do my true due diligence! Such as thorough research via prior postings in this forum.
So as some of you may already know, I had a first interview for a programmer job at UCLA. The second interview is coming up, it's supposed to be this Thursday, but I might try to postpone until Friday. Too much stuff going on in my life lately, including doing 2 different part time jobs and an extended relative who passed away recently, that's the reason I'm going down to LA for an in-person interview, since the last interview I did via Skype. It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP. I suspect its also because the 1 and only programmer there, who's been there for like 30 years and may be retiring soon - doesn't want to learn something Totally new. And, also wants to minimize the transition! They are asking me to propose what I think is the best option. They have mentioned several options such as Fox-in-Cloud, the Alpha software, and even Servoy. They did not bring up things like Lianja, XoJo, or X# the open source X-base language.
I know that Fox-in-Cloud even offers a type of Conversion Assistant - which looks really Great! But, once its converted and running in the cloud - I'm assuming that making updates to the system actually means programming in something that is not actually FoxPro - as I think its Javascript & HTML. But, I could be wrong - and am sure Thierry will correct me.
There was also some recent discussion on X# which looked like a potentially great option. But, I heard that via the last posting - the FoxPro version of the code wasn't really ready yet!
They also told me that they have already been working with Alpha SW - and in discussions with them for several months. Which makes me think they are already leaning towards Alpha. A quick review of old postings in this forum did not show a lot of discussion or users of Alpha. It would really be great to hear from some Alpha users!
Anyway - any and all input would be greatly appreciated. I've seen Numerous discussions about a number of these technologies here in the forum over the years. But, honestly - I never truly got involved with any of them - until NOW!
Regards, Kurt
[excessive quoting removed by server]
-
Alan Bourke -
Charlie-gm -
Dave Crozier -
Ed Leafe -
Eric Selje -
Fletcher Johnson -
Jean Laeremans -
Johan Nel -
Koen Piller -
Kurt at VR-FX -
Matt Slay -
Stephen Russell -
Ted Roche -
Thierry Nivelet -
Vince Teachout