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 am interested in developing a new SQL-based RDS which can generate prototype CRUD-oriented 4GL code which can then be easily customized. So I am looking for opinions, suggestions, etc. in what features should a new RDS have?
I have looked at several products. FileMaker is more or less the type of product I'm looking for, but it's not SQL-based. Informix 4GL and 4Js are what comes closest, but the lead time for customizing/debugging seems to take a long time.
Depends on the market you are aiming for. In your place, my first decision would be whether to link it to a specific RDBMS implementation (which would be Oracle, SQL Server or mySQL) or to try to make it flexible to use amongst any of the major databases. The latter would obviously add massively to the complexity (development, testing, support).
The second would be the OS platform. Something that is specific to Windows (or perhaps Windows Vista/7 upwards) or can be used on Linux, OSX etc. 32bit/64bit would also be a consideration here. I'd need to know that it can run on 64-bit Windows 7 at least.
Thirdly, what do you develop your Rapid Development Tool in. Dot Net would pretty much be Windows only. Java or Python offer more choice.
Fourthly, are you making this as a commercial product, or as open source (or both). Bluntly, if I was looking at buying such a tool to develop my XYZ product in, I'd be looking at long-term support. If the tool doesn't have a five-year pedigree of ongoing support, I'd be very hesitant and would only consider it if it came from a company of the likes of Microsoft/IBM/Oracle/Apple with some serious history in the field. And even then I would be skeptical (search on Microsoft's Oslo/Quadrant/SQL Server Modeling).
I'd also be looking for professional tech writers for the documentation.
See the feature list of Oracle Application Express for some good ideas.
I've used a few of these tools and things that come to my mind are:
1/ automatic joining on foreign keys
2/ keeping columns in the same order as the table in the code
3/ dynamic code generation, no separate code generation stage
4/ undo on table changes
5/ prototyping features to enable actual data to be modelled during development
6/ hide column feature
7/ SQL import for those tricky bits
8/ code locking on tricky bits
9/ version control
10/ segmentation into namespaces
11/ Language templates for easy addition of extra code languages
I think going to an intermediate 4gl first would be good and then a second stage to render code in the language of choice would be good.
I hope this is of some use to you, good luck!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have recently heard about Magic programming language from several sources and didn't recall ever hearing about it before. It was mentioned that it is a programming language from Israel.
I did some googling and couldn't find much information about it. I couldn't find any code examples, and wikipedia didn't have any information on it either.
I think this is the site for it http://www.magicsoftware.com/en/products/?catID=70 though I am not sure, as it mentions uniPaaS instead of magic. However other material on the site indicates that this is the new name for it.
I was interested in learning more about it from it's practitioners, rather than the company. I saw several claims on the internet that it provided really fast application development, similar to claims made by RoR proponents when it came out.
How does it compare to VB?
Is it still a better RAD tool than current .net or mvc frameworks like django, ror ...etc?
How hard is it to learn?
If you can post some sample code it would be most helpful as well.
Could this site be it? Though it links back to the page above.
You're right my friend, Magic is the original name of the "programming language", nowadays is called UniPaaS (Uni Platform as a Service), I use it to develop some business application. Maybe is the fastest way to create an applications(data manipulation), you can create apps in just a few days, but like everything in life has its own drawbacks:
it's very weird so that makes it
difficult to learn.
you do not have all the control of what's happening in the background
and you have to pay a lot for licensing (servers,clients, etc)
If you are interested in learning this, you can download a "free" version of the software that only works with sqlite databases called UniPaaS Jet.
Magic Language is as it’s called today uniPaaS, it used to be Magic than eDeveloper and now uniPaaS as PachinSV menchend before.
uniPaaS is an application platform enabling enterprises, independent software vendors (ISVs) and system integrators (SIs) to more successfully build and deploy business applications.
You can download the free version of uniPaaS Jet here: http://web.magicsoftware.com/unipaas-jet-download,
try it yourself and see how easy it is to use.
Magic technology as you descried is a Magic Software Enterprises tool (uniPaaS), you can find more information on:
official website: www.magicsoftware.com/en/products/?catID=70&pageID=55
uniPaaS Jet developer group on facebook: https://www.facebook.com/groups/unipaasJet/
Magic developer zone: devnet.magicsoftware.com/en/unipaas
Let me know if you find the information helpful
Bob
As PachinSV explained, there is a RAD once called Magic, then eDeveloper, now UniPaaS. This RAD is dedicated for database applications. Programming in this RAD does not look like anything else I know, you mostly don't write code as with usual languages, but it is nearly impossible to explain just with words. The applications are interpreted, not compiled.
As PachinSV said, when developing, you must follow UniPaaS' way of doing things. This is probably why so many people never manage to use Magic properly: if you thought like Magic before learning about it, then you will adapt to it easily; but if you have a long and successful experience using other database development tools, then often the Magic paradigm will never become natural to you. The learning curve is quite steep, you must learn a lot of things before being able to write a little application.
Previous versions stored the "code" inside a database table. The last version, UniPaas stores the code in xml files. I could send you an example, if PachinSV does not answer you before. But the files are pretty big: the smallest xml file I have in a test app is 4000 bytes, and any application is made of at least 11 files, an empty application is 7600 bytes. You must also understand that developers never use those files (they are undocumented AFAIK), they are only the storage format used internally by UniPaaS. The only way to use them is to set them up as a UniPaaS application.
I'm still an active MAGIC Developer... This is the old name used and its a completely different paradigm like some of you mentioned. I've been developing it from Magic version 8.x to eDeveloper 9.x to 10.x then renamed to UniPAAS.
The newer version is much easier to use and it is still very RAD in the sense that there is little or no code you write... a lot of the common programming tasks like IO, SQL command...etc is handled by the tool and is transparent ( so even less code to write since we use it in almost all types of applications)... Its mostly an Enterprise tool... you wouldnt use it for small application...
You can download the free version to learn the paradigm... but the enterprise licenses are expensive.. you need both the development tool and the runtime license if you want to deploy... so it can be costly for small scale projects...
I enjoy it personally, especially when you have to do quick proof of concepts or a quick data migration or porting onto any db platform and bridging any existing system through a wide range of gateways they provide with the licensed version.. It is up to date with the commonly used web technology out there...like SOAP, RIA ...
It's more popular in Europe... The HQ in the States is in Irvine... we used to have 2 branches in Canada but it closed down in 2001 .... Visit the Magic User Group on Yahoo... Its a very active forum with lots of cool people who will help you out in your quest...
http://tech.groups.yahoo.com/group/magicu-l/
I Programmed with Magic for 6 years and found it to be a amazingly fast tool, easy to understand if you are a competent database programmmer because all operations are really about data manipulation. It is certainly a niche area develop in and because of this jobs are few and far between. As it is interpreted there are really no bugs to make. It will work with many databases/connections simultaneously but there is a big memory and processing hit.
Drawbacks :
Little control over communications between machines and devices
No mobile API as yet
Niche area so few skilled practitioners or companies willing to invest.
Good Points :
You can say you are a Magician; you can impress people with uber fast apps development (really)
It is easy to understand if you don't have a PHD in Maths
zero programming "bugs" can creep in. What you do is what you get.
Developed in The original Magic PC referred to by several of the above folks.
It is exactly this: FAST, FAST, but expensive and rigid in what it will allow you to do. It works on a tick tack toe like matrix. Dropping in commands into the various sections determines when they are run. The middle column is run indefinitely until you break the cycle. It is like a do Until loop. If you have to do an item once you put it into this infinite loop and end it after one cycle.
The first column procedures are run first, ONCE, before the infinite middle column is run. The 3rd column of commands is run after the infinite cycle, once. It is very efficient and logical once you get over the idea of an infinite loop.
Types can be specified and an associated program to present the type. Then everywhere the type is used all the settings automatically kick in. I like especially that one can write the program and 5 months later change the name of a variable and it is carried throughout the program. In fact the program does not use your name for anything. The internal name of any and all variables is hidden to the end user, so of course it is not a problem to change a name. It takes a minute to write an input program for any table. It takes a minute to write an export/import program for all the data files in the database.
Attaching to a type of database like Btrieve or SQL independent of the program itself.
I stopped using the language because they demand more for the runtime engine than I could charge for the programs I wished to run with it. Bill Gates went the opposite direction. VB is superior in control and being able to drop `10 datagridviews onto the same screen, but development is 10 times slower.
It's niche then is PROOF of concept for a program in a big company or conversion, importing, exporting for a development company. It is good for $25k programs that are database heavy and not going mobile.
uniPaaS, Magic PC
I did some Magic work around 1993. It was a DOS based 4GL that came from Israel. Haven't seen it since.
How does it compare to VB?
It doesn't.
Is it still a better RAD tool than current .net or mvc frameworks like django, ror ...etc?
If you mean "is it more Rapid", then yes, otherwise no.
How hard is it to learn?
About as hard as learning MS Access.
Coincidentally, if you want to get an idea of what it is and how it works, I've found that comparing it to MS Access is handy. It works in much the same way from a user's or developer's perspective. Obviously what happens in the background is vastly different, but if you've ever developed a form in design view in Access, Magic will seem very familiar.
Google tells me there's also MAGIC/L. All I could find about it was this blurb:
A procedural language written in
Forth. Originally ran on Z80's under
CP/M and later available for IBM-PCs
and Sun 3s.
The only Magic programming language that I know about is one used by a company called Meditech. It's a proprietary language derived from MUMPS.
The language is truly miserable - here's a sample.
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 2 years ago.
Improve this question
I work on developer tools for a particular product. There is a competing set of tools for the same product produced by a different company. The user-base is split roughly 50-50 between us.
Recently, the other company has introduced scripting to make their own tools extensible by end-users. This is a feature that we have had planned for our tools for a while, but it is only now that we are able to start implementing it.
My question is: should we try as much as possible to collaborate with the developers of competing product so that end-user scripts can be shared between users on the different products? We would obviously require different implementations, but share the same syntax. This would obviously be better for the community as a whole since there would be more interoperability.
The downside of collaborating like this is that the competing product's scripting language is slightly tailored towards their own implementation. We would have to jump through a few hoops to create an implementation for their scripts on our platform. Or, we would have to somehow convince our competitor to modify their scripts so that they are platform agnostic.
So, to rephrase my question: should we try to collaborate, thus making our community happier, or should we produce a competing scripting language that is more appropriate for our platform?
I realize that this is a very general question with no single right or wrong answer. What I am looking for is a good explanation of the pros and cons of each approach.
I would write something that is specifically tailored towards my own system (don't compromise your technical quality) and then release and fully support a compatibility layer that allows my competitors scripts to run on my system (make it easy for users to migrate).
I'd stay away from doing things that will try to lock people in and cripple them if they move. These tactics worked once upon a time but in this day and age don't really cut it any more. I'd even go so far as to actually (unofficially on fora etc.) help people who are having trouble porting scripts running on my system to my competitors.
Another way to ask the question (and to answer) is to wonder WHAT KIND of script language is DESIRABLE FOR USERS.
If your competitor went a lock-in route with a proprietary scripted language, then please your users (and get a competitive edge) by using a STANDARD scripted language.
Doing so will immensely increase the value of your tool as many persons ALREADY know the scripted language.
Nobody wants to learn a new language.
Would building a unified scripting language harm your customer-base or give the competitor the competitive edge?
Obviously if you want to lock in customers, go solo which will prevent your customers from easily switching over to the competitor's product (sounds a little like Microsoft tactics) or if you know your product is superior, a collaboration will allow you to get customers from the competitor in which case customers will have the choice to choose which business model suits their needs, make a choice based on the quality of the product as a whole as well as which features they really need instead of being locked into an invisible contract due to the choice they made initially.
Going the collaboration route will also put your company in a position where developers will respect your company (for not being a greedy monopoly monster) instead of boycotting it due to their "moral" beliefs in open standards.
I would say that if possible make it compatible, not so much to cooperate but to compete. Making an incompatible solution would lock you customers in to some degree (you don't have any yet with a lot of scripts - so not much gain), but making a compatible solution keeps the door open for customers of your competition to migrate (they might have some scripts by the time you ship yours).
Just my 2cents
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 5 years ago.
Improve this question
As the years go by we get more and more applications. Figuring out if one application is using a feature from another application can be hard. If we change something in application A, will something in application B break?
We have been using MediaWiki for documentation, but it's hard to keep the data up-to-date.
I think what we need is some kind of visual map of everything. And the possibility to create some sort of reference integrity? Any ideas?
I'm in the same boat and still trying to sell my peers on Enterprise Architect, a CASE tool. It's a round trip tool - code to diagrams to code is possible. It's a UML centric too - although it also supports other methods of notation that I'm unfamiliar with...
Here are some things to consider when selecting a tool for documenting designs (be they inter-system communication, or just designing the internals of a single app):
Usability of the tool. That is, how easy is it to not only create, but also maintain the data you're interested in.
Familiarity with the notation.
A. The notation, such as UML, must be one your staff understands. If you try using a UML tool with a few people understanding how to use it properly you will get a big ball of confusion as some people document things incorrectly, and someone who understands what the UML says to implement either spots the error, or goes ahead and implements the erroneously documented item. Conversely more sophisticated notations used by the adept will confound the uninitiated.
B. Documentation isn't/shouldn't be created only for the documenters exclusive use. So those who will be reading the documentation must understand what they're reading. So getting a tool with flexible output options is always a good choice.
Cost. There are far more advanced tools than Enterprise Architect. My reasoning for using this one tool is that due to lack of UML familiarity and high pressure schedules, leaves little room to educate myself or my peers beyond using basic structure diagrams. This tool easily facilitates such a use and is more stable than say StarUML. (I tried both, StarUML died on the reverse engineering of masses of code -- millions of lines) For small projects I found StarUML adequate for home use, up until I got vista installed. Being opensource, it's also free.
With all that said, you will always have to document what uses what, that means maintaining the documentation! That task is one few companies see the value in despite its obvious value to those who get to do it. . .
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 9 years ago.
Improve this question
Jeffery Palermo says 'Classic WebForms More Mature Than ASP.NET MVC': "Is Classic WebForms More Mature Than ASP.NET MVC?".
It seems to be subjective, but what I want to know is, what exactly "mature" software is?
The answer is very subjective. But basically if the software can answer to most of these criteria (in no order of importance):
secure
reliable
actively maintained
has active community
field-proven
Then it can be considered "mature".
It is important to note that different clients would expect different levels of "maturity". A large corporation would demand that the software it uses is secure enough to protect its sensitive data, and that the software is supported by a support rep available 24/7. As opposed to a small private project of your own which you might care much less about security, and you do not need (nor can afford) a service package which includes 24/7 customer support.
So ,maturity differentiates according to the client, but the basic criteria remain the same.
Mature is when people have figured out how to deal with it.
(And we're talking about development platforms not about end-user apps, aren't we?)
For example, javascript only became mature with the introduction of prototype, jquery and the like.
Before that, people tend to code strange things they they'd regret.
So you're asking for subjective opinions on a subjective topic. :)
I would say, mature would add the following characteristic to a technology:
People know how to use it, know its possibilities and limitations
People know what the typical usage scenarios are, patterns, what are good usage scenarios for this technology so that it shows its best
People have found out how to deal with limitations/bugs, there is a community knowledge and help out there
The technology is trusted enough to be used not only by individuals but in productive commercial environment as well
Reduce Subjectivity by Developing a Measuring Tool for yourself.
My Criteria are for Business Software:
Feature Rich - handle lots of Business Rules
Flexible - Selectable Features via Parameters & Configuration
Stable - Few, if any bugs causing malfunction such as crashes
Well Documented - User and technical Documentation
User Friendly - as attested and recommended by users
Robust - Not very much fazed by events such as power failures and erroneous user input.
Installs & Runs "out of the box".
Take all the Criteria and place it in a spreadsheet with columns rating from 0 - 5 and do a rating by ticking the column corresponding to your rating of each criteria.
If overall score is 25 or better then the software is mature.
If the score is 15 to 24 then the software is average.
If below 15 then the software is immature.
Mature software has to be whatever you mean it to be. I don't think you will find an easy mechanism for measuring maturity, and everyone's definition is going to differ anyway.
It's always going to be a subjective view I'm afraid and therefore subject to a lot of argument.
I would say that mature software is stable, well documented, widely used and well tested.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 9 months ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I read this term a lot. What exactly is a legacy database? I ask because I had thought it meant an old database like dbase or rdb, but I don't think I'm right.
When looking at RoR or Django and "legacy database" integration, what does legacy database really mean? Is it different than a generic term "legacy database"?
In the general context, it can refer to any of the older database technologies.
In a more specific context, it can refer to a database system that was inherited by a team from previous project owners.
legacy: anything from the past that keeps coming around to haunt you.
A legacy database is generally something that you will have to inherit and base some of your design decisions around. Most companies that put out work may already have some other (usually horrible) solution and you need to give them a bigger and better product...
BUT
It has to work with all of their old legacy data. The company is not going to want to manage two different applications just so they can keep all their old records. You will need to develop your solution to be able to migrate the data from the legacy system over into your system. This can have a massive impact on the overall design of the new database, because it cannot stray too far from the previous without introducing a lot of problems in terms of data integrity.
It's usually derogatory in my experience:
Something no-one wants to touch in case it breaks
Databases that can't be maintained (say that SQL 6.5 box lying around)
Someone else's badly designed and implemented database
Something that someone is trying to replace
Supported by the 93 year old wierdo
If it's in-use but still has maintenance or development activities, it can't be legacy...
Edit:
Given the age of the SQL language and the RDBMS, everything is legacy (including my new system due next year) compared to the software listed. At what point does Ruby turn legacy from the database perspective..?
We mostly use the term 'legacy database' as a db schema we can not 'easily' modify without breaking other software/systems using this schema.
this sums it up pretty well.
[edit] Broken link. Here's the quote from FOLDOC:
Legacy System -- A computer system or application program which continues to be used because of the cost of replacing or redesigning it and often despite its poor competitiveness and compatibility with modern equivalents. The implication is that the system is large, monolithic and difficult to modify.
If legacy software only runs on antiquated hardware the cost of maintaining this may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.
Flat file, hierarchy, and network databases are usually referred as legacy databases. They represent the ways people used to organize information in prehistoric times — about 30 years ago.
Legacy is used to denote the old thing. legacy database is something which continues to be used because of it cost of replacing and redesigning it.
In general context refers to old code inherited. Tipycally cobol code.
It is used for code which it is still used for historcal reasons.
It applies also for DB schemas