Related
In short, I am looking to create a POC (proof of concept) for an interface I have designed for aggregating data from several different sources. Currently I am just using flat tables in SQL with no relationships (although there are fields that are in the data for that purpose) to store the data, which is being gathered by various means (mostly PowerShell scripts). I also want it to be modular enough so I can add hooks to REST calls to other sources. So, if I make a call to get data about a certain asset, I don't have to know where that data is at that level. The middleware will know where to find it and use the appropriate method to get it (SQL, REST, etc.).
I have been in IT for over 31 years, I have experience with SQL (and have been a professional DBA at one point), a few scripting languages, and wrote a similar app in C# at one point, but I was given a template interface from a profession developer and I just ran with that and changed it as I went.
I want a high level view with colors indicating general health of a location, and the ability to search the data for assets (this could be anything from a VM, BM server, ethernet switches, FC switches, connected SAN, hypervisors, vCenters, Nutanix clusters, etc.) to find their location, health and most importantly, their connections to other assets.
I know a little about everything, enough to be dangerous in most and some a master of. What direction should I go here? I know BASIC, PowerShell well enough to call myself an expert, but more than likely, just a hacker. I know the basic concepts of coding well enough (I was an adjunct at a CC 20+ years ago) to teach it to others. I want to use a language I will be able to hand over to a professional to maintain once we have a new DevOps member on the team.
EDIT: I wrote a very small program earlier this year using React. That was broken into the interface and the 'middleware' with two separate project. Java is not an intuitive language for me and I could go this direction again, but I am looking for possible alternatives.
I'm not sure there's a 'non-developer' way of doing this unfortunately. If you really want to do this yourself, I'd suggest a C# API since you have some experience in that (even if it's minimal, it's still comfort), and luckily for you they just released minimal API's which should make your life much easier (https://dotnetcoretutorials.com/2021/07/16/building-minimal-apis-in-net-6/).
In terms of actually displaying the data, if it's a really simple UI I'd just keep it simple and use JavaScript and HTML/CSS (ie no frameworks such as React). It's a POC, and if someone comes in and wants to move over to using a framework because there's more work to be done on it, it's not that hard to take your existing code and move it into something more modern. But if it's small, a framework would be over engineering this, especially if you need to learn it all.
For smaller projects like this, you can kind of learn the code you need for the project, without needing to truly learn to code. Get your components from a library like Bootstrap (it's basically premade elements like your dropdowns, progress bars etc, their documentation is pretty good), and keep it as simple as possible. Good luck!
I am working on a website where users can crop a specific part of an image to be identified (e.g. company logos). The cropped image is submitted to a database to be identified by an internal system using machine learning techniques.
My problem is that I don't know where to start as I have no experience in the field of computer vision or machine learning. Here's what I would like to achieve as a start:
Extract features from user's cropped image as test dataset
What is the 'form' of the features? Is it an array of numbers?
What kind of database should I use for this purpose?
Implement machine learning algorithms on the server side
How do I 'embed' or offload the processing parts?
Which language would be relevant for this purpose?
Any advice would be greatly appreciated.
You probably need to get familiar with one of the Computer Vision libraries such as OpenCV. It has what you need, including the implementation of machine learning algorithms.
It's basically a CRUD application.. Are there any Access add-ons to simplify development of screens, reports, SQL stored procedures? I'm not familiar with VBA or Macros. I need to be able to control cursor movement, perform conditional if's, what happen before or after entering a value, table lookup's, etc. etc.
I've tinkered around with Access, already have a schema and relations defined, but I imagine the learning curve will take quite some time and heard it takes time to get up to speed on VBA and Macros.. I've even heard its better to develop this app with a VB add-on called RadVolution. I would actually rather develop this app with as a touch-screen POS-style app, but not aware of any RAD Tools or SDK's for that. I'm familiar with Informix-SQL and non-visual Basic, but have no C or Object-Oriented language experience, I'm old school procedural language (Basic, COBOL).. Anyone willing to work or help me with this conversion project?
A real strength of Access is its simplicity, it is described as a "rapid application database development and reporting tool". For the most part, you do not need any VBA for forms and reports, if it looks complicated, it is likely you are doing something wrong. The only question is how many users do you expect to have and where do you expect to run your application? A lot of bad press is due to misuse, used properly, Access can be very handy indeed.
You really don't want some type of automated conversion anyway. The reason is that you need to CHANGE how you done some these things to work with the architecture change that occurs when you move from one development system to another.
An automated conversion is probably not much worth it since so often how things were done in the previous system will be done differently in the new system. For example when people came from DOS based (text screen based) FoxPro applications to Access there was two significant changes the developer had to make:
1) No record numbers in Access
FoxPro (which was a dBase compatible clone) had its roots in being a singer user file based database system. So this was system designed from the ground up to operate on your personal computer. This meant the file and programming system used sequential records from a file on the hard drive. This model was much like punched cards data processing. And I should point out there's nothing wrong with this type of model, but the software approaches and designs you used for punch card data processing is somewhat different then compared to interactive multiuser systems.
What is SIGNIFICANT and most important here is on a conceptual level when you write software inside of Access then record numbers or so call record order as a conceptual idea that as you write software is NOT relevant. However in Foxpro assuming record order was a legitimate assumption. This is an architecture change. I remember back in early 90's that in many forums one the FIRST questions from long time Foxpro developer asked is:
How come access does not have record numbers like Foxpro does?
The answer was simple and that answer is/was Access considers data a big huge unordered bucket of data. In other words if you wanted some order to your data, you had to add something like an invoice number, perhaps even a time stamp, or something else. For something like a sub form as a general rule you can rely the auto number, but that auto number should never been seen by the users. No matter what, you had to use a SQL query that SAYS what order you want.
Another important detail is if you add 10 records to a table (even in single user mode), if you then retrieve those 10 records from that table, you can NOT assume the record order will be the same as when you added them. In other words if you need a particular order, you have to sort that data by some column. This is an assumption that FoxPpro, or people who used FORTRAN and punch cards could always assume. Such assumptions cannot be made when using Access. In fact this assumption cannot be made with any modern server based system such as SQL server.
However this "lack of" record order assumption was SIGNIFICANTLY important later on down the road. This "assuming" means that THEN your WHOLE Access design was now based on assumptions that ALLOWED easy conversion to multiuser systems OR that of client to server (both need this assuming).
So your software designs could never say go to the next or previous record (based on record number) since records are now a mumble jumble of records being entered by different people. The next two reocrds in that table (or previous ones) might not be yours! So keep in mind that while Access allows you go to the next/previous record inside of a form, it NEVER does so based on record number but ONLY on the data that's been CURRENTLY loaded into that form. In FoxPro you would often move around by actually using command that said go to record 4 in the table.
In Access we don't say go to the 4th record in the table. You might say go to the 4th record in some data that we pulled from a table into a form, but that 4th record has absolutely nothing to do with the actual physical fourth record in the table. A small change, but one that was required for multi-user systems that we started to use 10 years later (so the smale change in software produced beneifts 10 years later!).
As a general rule this architecture or philosophical concept of record order in a table is not a very big deal at all for most of the software you write, but if you needed to use SQL server later on, then it was a big deal. And I should point out that since your software is written using SQL in mind, then at least in this regards you are in good shape.
However for those that wrote applications over 4 to 5 years based on this simple record order assumption, it would have to be completely RE architectured for multiuser environment or even for Access.
I should point out that FoxPpro eventually became a brilliant object orientated client server development tool, but had to go through a significant metamorphosis than what the original architecture and designs that a typical FoxPro application had.
2) Event driven programming
In these older text based systems you tended to write one large major startup program with a main menu system included. Choosing a menu option would then perhaps branch to a section in the main program or perhaps branch out and call another portion or part of the application. However to its credit, FoxPro and a good number of dev tools did have some event type of setup, but they were not ideal. It best to re-do much of how those screens and UI will work when droping text based UI anyway - this is VERY much the case with new touch based and gesture based UI wew now see such as smartphone or iPad.
In event driven programing we as a general rule don't have that large startup program. And we also don't have a large code base for the main menu system. In event driven programming you have code that RESPONDS to a user click. Or you have code that responds to a record save. Or even navigation to the next record.
So in event driven programming you click on a button then a rather SMALL bit of code would respond to an event by the user (in this case a mouse click). So this type of programming is what we call event driven programming.
All of a sudden, your application is now not being driven or run by one big large main program, but in fact is a whole bunch a little tiny small programs stitched together by event driven code.
For people coming from an DOS based environment, or even QuickBasic, GW-basic or even many of the older text based database systems, then having one large startup program with some menu system was common.
And having a large program to "edit" one data entry screen was common.
Now such designs are turned upside down in which your menus and click events were now going to run and call code. Thus these very small routines would THEN call other bits of code to allow the application to run.
The main reason for this architecture change was the introduction of the mouse and the graphical user interface. In other words when looking at a data entry form, in place of tabbing along to the next field in a complex data entry form the user can now click on many different things and even click on the menu bar. So they can click just about ANY place on the form. This means that having one big program to run and maintain the form data entry is/was not possible. If your code was waiting for input in the Company field, then how could code be run when the user clicked on a menu bar option? Since the user could do many things in many different order than what the original programmer would anticipate then we need a different way of writing code.
At the end of the day with a GUI then code branching became too complicated for the developer to anticipate. Hence the concept of event driven programming was born to solve this dilemma. In other words our code now runs and responds to the users actions and our code is not waiting for the next user input sitting in some line of code.
Again this was a small architecture change, but many developers struggled with this conceptual change in approach to software development. On the other hand all of these changes occurred in the early 90's.
The next big change the course was object oriented programming. Access does allow you to build class objects, but it is not a full OO system.
Today the next big challenge and change and architecture is the ability to build web based systems. Again a zillion changes occur due to having "solve" different programs for the developer. Access 2010 allows one to build web based systems now, and this conceptual and architecture change is a GREATER challenge than that of learning the new macro language we have for developing web forms with Access. So a "change" in how you design software has to occur again.
I should point out that these major changes in the industry happen about once every 10 years or so.
My point of all of the above is, even if there was some automated conversion system, it really would NOT work very well because the architecture of the systems are very different. You would be handicapped by all of the old assumptions.
I also note you been around asking about using using Access in various Access forums for what about two years or even more now? You seem to be looking for some magical silver bullet that will solve your problems. There is not one!
At the end of the day you need a sit down and obtain some basic Access skills or hire someone. You need to learn the system you going to use and THEN come up wth a desing that works with Access and "is" for Access.
I should point out that the desing you choose for Access would not necessary say work with vb.net either. So don't try and take an existing desing and put a square peg in a round hole. What works in one system in terms of UI will NOT work in other systems.
I think you been fooling around much too long here. About the only good part of delaying so long is you now have to consider if you want to adopt a set of tools that allows some web integration with the application?
Office 365 works great with Access web publishing, but for complex mature applications, I think the web side is somewhat weak (but you can write hybrid applications with Access 2010 now). Here is an video of Access web in Action:
http://www.youtube.com/watch?v=AU4mH0jPntI
In the above, I swtich to running the applicaiton in a web browser. This app was 100% built in Access, including table trigger logic and code (no 3rd party tools or coding system was use - ONLY Access was used).
Considering technology right now, perhaps you have this run on iPads as they walk around in the store? There a lot of new choices here for software, but if you sit around for another 2-3 years, then you be looking to use something other then the iPad and some "other" new system.
You can certainly write your applications as more "touch" friendly in Access. However some of the new gesture based actions do not transfer to web. For example, we cannot disable keyboard input in a combo box, and this ability would REALLY help the Access application running on an iPad if we could. The reason being is when we tap or hit a combo box on iPad then it pops up on the screen the soft keyboard and we do NOT want this. And some of a really slick gesture date pickers etc. don't translate to web on the iPad (they do want you to write native apps after all!).
Microsoft Access is pretty simple as it is. There are wizards for form and report creation. You can then modify the events to perform all of the tasks you mention.
I suggest getting a good book on the subject and delving in. I learned a lot (years ago) from the Developer's Handbook series including Access Developer's Handbook and VBA Developer's Handbook.
It appears you've already made the decision to migrate your entire system to MS Access but have you ever thought about first skinning your IDS system with a platform like Grails? It's cross platform and can be deployed on any operating system that supports Java.
You could deploy the resulting application as a single user, single site or shared system depending upon the client's requirements.
Once you have migrated and enhanced all of the existing functionality it will then be trivial to convert the back-end database to another engine such as PostgreSQL.
I'm currently in the process of enhancing a legacy Informix 7 (SE/ACE/4GL) application for a client and it is working out really well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have evaluated several development tools for converting my informix SQL-based app. They are: Genero/4Js, FileMaker, Oracle APEX, VFP, Clarion and Access 2007. I have a CRUD pawnshop app (see video-demo www.frankcomputer.com) This app centers on customers who pawn, sell or buy merchandise. I need to have one CRUD multi-table form which displays one customer master on the top half with all of the customers associated items which they have pawned, sold or purchased on the bottom half. Can CRUD be accomplished from within one form in Access? The main reason I'm leaning towards Access is because of its integration with Excel, Word and other modules, plus many people have it and experienced using it, plus it's Microsoft. Can anyone who has developed apps with Access tell me if I can mimic my INFORMIX-SQL based app and what limitations does Access have? Also, can a touch-screen POS front-end like Microsoft Dynamics be used or are other POS application generators/rapid development systems available to re-write my current app?
I suspect if you ask Foxpro developer, they would tell you that's the best tool of choice.
And I'm sure if you ask a filemaker developer, they would tell you to choose their tool.
So much of the question is, for the most part if you ask an access developer, that developer would also answer yes.
I would be hard pressed to imagine that all of the above tools you mentioned above, all of them have the capability of displaying information from more than one table in a screen. That's pretty much a requirement for any development system today. So in a nutshell, you're really asking the wrong question here.
I don't think the question is do they have the capability of displaying information from more than one table. They all can do this. Perhaps a fair question would be how much work and how well does each product slice and dice together these multiple tables?
In access you place text boxes and controls on a form, and to display related data, you can you place a control called a sub-form control. This approach allows you to model this classic can typical master to child record table relationship, and do so without having to write one line of code.
And of course you're not limited to one to many, but you can actually insert two sub forms side by side, and have a one to many, and in turn have the 2nd sub form control display many more records from that second table.
Here's a screen shot of what I mean:
In above you have one main record at the top with information about donation date and event. On the left you have a list of people and their donation amount (one to many).
Then on the right side, for each person, you have the donation amount split out into multiple accounts. (and the green box shows red when the amounts don't balance).
So, the above creates that classic accounting problem that just about every accounting package from Quickbooks all the way up to hi end accounting packages have done from day one when splitting out funds to multiple accounts.
The above form has very little code in it, and most of the relationships and setups and filtering and displaying of the child records is all handled automatically by access.
So at the end of the day, I'm pretty much of the view that all of products you mention above are capable of modeling and developing these types of screens. And, they all will result in an screen and user experience that would be relatively similar to what you have now.
Now course I'm a biased towards access, and I believe that I can build screens like the above quicker, faster, and with less hassle less code and effort than most of the other products you mentioned .
However, at the end of the day what platform and tools you use and find as appropriate is certainly not going to be centered around the ONE QUESTION and ONE CONCEPT that you have need to display multiple pieces of information on a form for multiple tables. As mentioned, this is gonna be given for any modern development system, including web based development systems.
Other considerations and factors is what type of reports, and outputs to you need? Do you need his column are reports, or do you need to send an invoice style forms type report to a printer that's preprinted invoice forms. I think these are bigger questions then your current question.
The real question here's not can any modern development system display multiple pieces of data on a form, they all can. The REAL factors and issues here are what platforms, hardware requirements, and systems do you need the software to run on?
So the issue is will some of the locations have multiple users? Will some of the locations need secure backup or some type of encryption? How do you plan to issue bug fixes, and updates to the next great version of the software?
Other issues are how many developers will you have working on this. What kind of distribution method will you use for the software. What kind of support infrastructure will you have to give customers support and installing the software. So, this list goes on and on and all these issues dwarf the question about the ability to display multiple pieces of information on one form.
In addition to all of the above issues, you need to consider your own training and skill set in development of software. To really master any software development system, you need to invest a considerable amount of your own time to learn. While I think the access is a very good RAD (rapid application development) tool, I will actually say that access has a considerably larger learning curve then say that of VB6 for example.
Choosing a platform is very much like a marriage, you have to invest enormous amounts of your time (months, and even years) to really learn and become proficient at developing software with such a system .
If you're jumping into a new set of tools, then the following list of skill sets needs to be taken into consideration **:
Stage 1 Innocent (never heard of the product)
Stage 2 Aware (Has read an article about X)
Stage 3 Apprentice (has attended a three-day seminar)
Stage 4 Practitioner (ready to use X on a real project)
Stage 5 Journeyman (uses X naturally and automatically in his job)
Stage 6 Master (has internalized X, knows when to break the rules)
Stage 7 Expert (writes books, gives lectures, looks for ways to extend x)
One should NEVER attempt a project with a team consisting with Stage 3 or lower people. (**** Page-Jones, Meilir. "The Seven Stages of Expertise in Software Engineering", American Programmer, July-Aug 1990).
So you just can't jump into a new tool and expect to be proficient at developing complex applications. I have an article here about converting a legacy application into ms access .
There are some great lessons in this article:
Notes on Conversion of a Pick (Multi-Value database) Application to a Relational database system.
http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000003.html
Good luck in whichever platform you choose.
Our company has a point of sale system with many extras, such as ordering and receiving functionality, sales and order history etc. Our main issue is that the system was not designed properly from the ground up, so it takes too long to make fixes and handle requests from our customers. Also, the current technology we are using (Progress database, Progress 4GL for the language) incurs quite a bit of licensing expenses on our customers due to mutli-user license fees for database connections etc.
After a lot of discussion it is looking like we will probably start over from scratch (while maintaining the current product at least for the time being). We are looking for a couple of things:
Create the system with a nice GUI front end (it is currently CHUI and the application was not built in a way that allows us to redesign the front end... no layering or separation of business logic and gui...shudder).
Create the system with the ability to modularize different functionality so the product doesn't have to include all features. This would keep the cost down for our current customers that want basic functionality and a lower price tag. The bells and whistles would be available for those that would want them.
Use proper design patterns to make the product easy to add or change any part at any time (i.e. change the database or change the front end without needing to rewrite the application or most of it). This is a problem today because the Progress 4GL code is directly compiled against the database. Small changes in the database requires lots of code recompiling.
Our new system will be Linux based, with a possibility of a client application providing functionality from one or more windows boxes.
So what I'm looking for is any suggestions on which database and/or framework or programming language(s) someone might recommend for this sort of product. Anyone that has experience in this field might be able to point us in the right direction or even have some ideas of what to avoid. We have considered .NET and SQL Express (we don't need an enterprise level DB), but that would limit us to windows (as far as I know anyway). I have heard of Mono for writing .NET code in a Linux environment, but I don't know much about it yet. We've also considered a Java and MySql based implementation.
To summarize we are looking to do the following:
Keep licensing costs down on the technology we will use to develop the product (Oracle, yikes! MySQL, nice.)
Deliver a solution that is easily maintainable and supportable.
A solution that has a component capable of running on "old" hardware through a CHUI front end. (some of our customers have 40+ terminals which would be a ton of cash in order to convert over to a PC).
Suggestions would be appreciated.
Thanks
[UPDATE]
I should note that we are currently performing a total cost analysis. This question is intended to give us a couple of "educated" options to look into to include in or analysis. Anyone who could share experiences/suggestions about client/server setups would be appreciated (not just those who have experience with point of sale systems... that would just be a bonus).
[UPDATE]
For anyone who is interested, we ended up going with Microsoft Dynamics NAV, LS Retail (a plugin for the point of sale and various other things) and then did some (and are currently working on) customization work on top of that. This setup gave us the added benefit of having a fully integrated g/l system, which our current system lacked.
Java for language (or Scala if you want to be "bleeding edge", depending on how you plan to support it and what your developers are like it might be better, but also worse)
H2 for database
Swing for GUI
Reason: Free, portable and pretty standard.
Update: Missed the part where the system should be a client-server setup. My assumption was that the database and client should run on the same machine.
I suggest you first research your constraints a bit more - you made a passing reference to a client using a particular type of terminal - this may limit your options, unless the client agrees to upgrade.
You need to do a lot more legwork on this. It's great to get opinions from web forums, but we can't possibly know your environment as well as you do.
My broad strokes advice would be to aim for technology that is widely used. This way, expertise on the platform is cheaper than "niche" technologies, and it will be easier to get help if you hit a brick wall. Of course, following this advice may not be possible if you have non-negotiable technology already in place at customers.
My second suggestion would be to complete a full project plan, with detailed specs and proper cost estimates, before going with the "rewrite from scratch" option. Right now, you're saying that it would be cheaper to rewrite the system than maintain it, and you don't really know how much it would cost to re-write.
I suggest you use browser for the UI.
Organize your application as a web application.
There are tons of options for the back-end. You can use Java + MySQL. Java backend will save you from windows/linux debate as it will run on both platforms. You won't have any licensing cost for both Java and MySQL. (Edit: Definitely there are a lot of others languages that have run-times for both linux & windows including PHP, Ruby, Python etc)
If you go this route, you may also want to consider Google Web Toolkit (GWT) for creating the browser based front-end in a modular fashion.
One word of caution though. Browsers can be pesky when it comes to memory management. In our experience, this was the most significant challenge in doing browser based POS You may want to checkout Adobe Flex that runs in browser but might be more civil in its memory management.
What is CHUI? Character-UI, as in VT terminals? Or even 3270 style?
It sounds like you need a 3-tier system - the database backend, a middle-layer that runs the bulk of the back-end business processes, and a front-end layer for the CHUI / GUI / data-gateway.
All three layers can reside on one machine; or you can distribute the tiers out to various servers. The front-end layer would control the actual terminals, whether they are VT-terminals, or a web-browser, or a custom-written 'client' application.
Make sure you have considered the hardware needs here -- are you going to have barcode scanners, cash drawers, POS debit/credit terminals, et cetra? If you are using a standard browser, it might be hard to reliably integrate those items. (At the very least, you're likely going to have to write special applets to handle them.)
Finally, consider the possibility of a thin-client technology on Windows. It greatly simplifies system management, since you only have to upgrade the software centrally. Thin-client PC's are cheap -- sub $200.
Golden Code Development (see www.goldencode.com) has a technology that does automated conversion of Progress 4GL (the schema and code... the entire application) to a Java application with a relational database backend (e.g. PostgreSQL). They currently support a very complete CHUI environment and they do refactor the code. For example, the conversion separates the UI, the data model and the business logic into separate Java classes. The entire result is a drop-in replacement that is compatible with the original (users don't need retraining, processes don't need to be modified, the data is migrated too). This is possible because they provide an application server and a set of runtime classes that provide that compatibility. The result of the automated conversion is not something that needs further editing before you can compile and run it. True terminal support is included so hardware terminals still work (it requires a small JNI library to access NCURSES from Java). All the rest of the code in the runtime is pure Java. No Progress Software Corp technology is used in the resulting system and it runs on Linux.
At least one converted system is already in production, running a 24 by 7 mission critical environment. It is a converted ERP system that their mid-sized pilot customer uses to run their entire business.