Good to hear how it went. On Wed, Mar 27, 2019 at 10:07 PM Kurt at VR-FX <v...@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 > > 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 <v...@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] _______________________________________________ Post Messages to: ProFox@leafe.com 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/CAJidMY+atgTaLm3wE4seT1Jx1_OFE_gMs+Lw+_3pqmXO=ax...@mail.gmail.com ** 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.
