Closest Generic Skill to Pick Universe to Groom

[Karthik Viswanathan]

All - Looking to identify a set of people to be trained in Pick Universe, What Generic IT programming skills in them would help groom faster. Thank you.

[Dawn Wolthuis]

Hi Karthik -- Can you provide more background? For example, is there a specific software application already written that people would be learning? If so, which one(s)? If not, are you planning to write new software with Universe and do not have anyone on the team with a background in it?

Any info you can provide will help us answer.  Best   --dawn

On Tue, Jun 14, 2016 at 1:58 PM, Karthik Viswanathan <vis...@hotmail.com> wrote:

All - Looking to identify a set of people to be trained in Pick Universe, What Generic IT programming skills in them would help groom faster. Thank you.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

--

Dawn M. Wolthuis

Take and give some delight today

[Karthik Viswanathan]

We have a won a new relationship where there is an application that runs on Pick Universe. We need to build a team who would support the application in the long run. while we are hiring Pick experienced associates from market. Iam looking for options to train some of my current employees in Pick. If I have to do so, what Generic closest IT programming skills  if any( e.g. Mainframe, FOXPRO, others...) would have comparatively lesser learning curve than the rest. 

[Dawn Wolthuis]

Once upon a time, we hired for VB skills. Additionally, anyone with old or new NoSQL database knowledge (instead of a SQL DBMS DBA-type) is helpful. If people know JSON or XML, for example, they will more likely groove with embedded lists rather than Comp Sci grads who took a database course who learned, incorrectly, that you were not supposed to do that -- that first normal form was important. It isn't.

If someone has COBOL or other procedural knowledge, that can also translate well to Universe BASIC.

I'm sure others have some better ideas, but that might be a start.  HTH.  --dawn

[Kevin King]

If you have a group that has no specific experience in Universe, I'd say the closest thing you'd want is some ability to do some shell scripting.  Most people who come to U2 from the web or SQL tend to have some hesitation about coding over telnet/ssh.  Shell scripting is the closest approximation to working in UV, I would think, though UV programming is light years more capable.

-K

[Karthik Viswanathan]

Thanks really helpful, for clarity does NOSQL relates to database (Universe?), any programming similarity that i should look for

[Karthik Viswanathan]

Does this relate to both programming and database aspect, or am i getting this completely wrong here. I also heard Universe is also looked as a rapid development tool like FOXPRO any insights around that ?

[Dawn Wolthuis]

NoSQL is a term that was initially found in the MV space and then introduced more widely (perhaps due to someone reading in this space or perhaps organically otherwise). By some definitions, the UniVerse DBMS fits into the category of a NoSQL (Not-only SQL) DBMS and not by other definitions (e.g. horizontal scaling, support for an arbitrary JSON or XML data structure rather than a perceived restriction on the nesting depth, etc). 

From my perspective of a non-1NF structure, which is where the original selection of nosql.com, .org were chosen in the MV space, Universe is a NoSQL DBMS. A MongoDB developer, for example, would recognize that a record in Universe is a document in MondoDB. A file is a collection. A field is a field.

I also agree with Kevin that getting folks who do shell scripting can help. Folks who do shell scripting tend to be closer to the machine than a systems analyst who knows the business application and codes accordingly. You might want skills of someone who has done some database work, is not an evangelist for first normal form, has done some scripting or procedural language and knows the subject matter domain.

Best.  --dawn

[Dawn Wolthuis]

FOXPRO surely matured from when I first encountered it. At that time, the people writing FOXPRO were often not "data processing professionals." They were more often PC people trying to get a PC to do whatever they wanted done, without the need for multiple users, for example. Then it ran on a LAN with multiple users, but still often with techies rather than information professionals. So, I guess I would not specifically seek a FOXPRO developer, but if you find a good information systems professional who happens to have FOXPRO in their bag of tricks, they should be able to learn UniVerse handily too.

Others might have more recent knowledge of the FOXPRO world.   --dawn

[Anthony Youngman]

On 14/06/16 21:40, Dawn Wolthuis wrote:

FOXPRO surely matured from when I first encountered it. At that time, the people writing FOXPRO were often not "data processing professionals." They were more often PC people trying to get a PC to do whatever they wanted done, without the need for multiple users, for example. Then it ran on a LAN with multiple users, but still often with techies rather than information professionals. So, I guess I would not specifically seek a FOXPRO developer, but if you find a good information systems professional who happens to have FOXPRO in their bag of tricks, they should be able to learn UniVerse handily too.

And like FoxPro, a good many Pick applications were written by users, not computer professionals. So I'd go back to basics and forget comp sci altogether. Look for people with good maths, language, or classics skills. With a couple of trained database people as well - just not first normal form fanatics, as Dawn says. Imposing an FNF structure on Pick *will* cause problems, but you do want to normalise your data, just don't put it into first normal form. auiu relational guys now go on about 3rd normal form, which you can store natively in Pick rather than modelling it in a traditional relational database.

As for rapid development? Not really. Relational is glacial development :-) Look at Dawn's website - http://www.tincat-group.com/ She was a manager who was converted to Pick because the relational projects she managed were always late and over budget, while the Pick projects were on time and on or under budget. Relational is the Audrey II of databases ... https://en.wikipedia.org/wiki/Little_Shop_of_Horrors_(film)

There's also the Rocket Software User Group - http://www.rsusers.com/cms/pages/home.wsp

And PickWiki - http://www.pickwiki.com/index.php/Main_Page

There'll be more resources out there. Just remember Pick is like SQL - it has become a generic term for several different databases, all of which are very similar.

And the other thing to remember is that while many old-timers still prefer the old-fashioned green-screen way of managing the database (which really is NOT that different from eg Transact-SQL to manage SQL-Server), there are plenty of modern tools which will connect to the database just like they would connect to a relational database. Oh - and unlike relational databases, which are just the database and *need* extra tools to actually be useful, Pick is a complete system and doesn't need anything extra which is why the old hands prefer the old ways :-) That's not to say that today's users would be happy with just the old system ...

And lastly, you've found us, we're a friendly bunch, get your recruits to join us. But *don't* expect this group to train them up for you. If they need help understanding stuff, we'll be glad to help, but we're all here because we want to be, not because we're paid to be ...

Cheers,
Wol