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 <[email protected]> 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.
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
