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.