I am looking for a simple, no frills, docker-compose based solution so I can start playing with some common tools, without having to devote lots of time into learning to configure the infrastructure. It should pull from the official images of the included projects, to make things super standardized and easy to move forward.
Ideally, I can have local directories mounted, so I can just edit my code directly, and have it served up through the container. Even better is to have the database stored similarly, in case I wind up liking it and want to port it into a project.
Edit:
Since it seems nobody gets it. The reasons for wanting this are:
No local installation of tools to pollute my development environment.
No rebuilding of containers as I change my code, learn, and test out features.
Not using any exotic features or special configuration, so official containers from the distributions should be sufficient.
Clean roadmap to scaling up to a real project. Acts as a template going forward.
Not spending time on tasks that are not relevant to the final goal (configuring a platform that may never be used).
It seems clear to me that a significant portion of development should use containerized runtimes for building/testing, without installing things on the real host. That would avoid a lot of hassles and conflicts, and allows easy revisiting of old development environments.
This seems like an obvious thing that should be readily available, just like the standard images that many projects provide.
As I am just looking to evaluate things, I'm not that picky about tools. A development language/framework (Node.js), a database (MySQL), and web server capability (anything). If it's PostgreSQL, MongoDB, whatever. I just don't want to spend days wrestling with setting things up, before I actually get to start evaluating the platform.
I tried asking this over on DevOps a few days ago. All I got was one snarky and unhelpful comment, which has since been deleted.
I have tried following a bunch of different tutorials around the web and answers given here, but they all fail, and I really don't want to get sidetracked debugging them.
It seems like this would be a common template for starting many projects, regardless of complexity or expertise. So, I'm really surprised I can't find it. It also seems like a good way to lure in new users, which should incentivize project maintainers to have these.
Related
I'm taking on the challenge of trying to test and develop with ERPNext. I'm new to ERPNext, Docker, Compose, Git, etc. I'm going to need to learn these from scratch.
What is the general most efficient way to install ERPNext (for testing purposes for now) on either a Mac or Windows computer?
Below are my criteria:
I need to be able to create backups and transfer them and implement
them to a different computer if necessary.
I'm also attempting to do this in as budget-friendly way as
possible. I'm probably not going to be spending money on hosting or
anything of the sort (completely free is the goal).
ERPNext needs to be easily upgradeable/downgradeable to different versions
The implementation of ERPNext will eventually need custom code/integrations
I've read that there are different methods of using ERPNext, depending on the OS, including VirtualBox, and Windows Subsystem for Linux. I'm looking for the fastest, least resource-hungry, and most versatile solution
I will check out the official ERPNext documentation, but I would also like to know other people's personal experiences and methods.
This is a big task to take on, so I'm looking for some advice before delving into this.
You can use frappe_docker setup to quickly get the environment up and running.
https://github.com/frappe/frappe_docker
If you want least resource hungry option, you can setup a site using bench.
https://github.com/frappe/bench
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm a Java EE developer and was just contacted by someone who wants me to put a quote together for an application for his business that can integrate with their MS Access "backend".
I was hoping to post this and just get a general high-level overview of best practices involved with MS Access Programming. I assume the program would be entirely in VB, but didn't know if I would have the option of writing something in VB.NET or (preferably) C#.
Also, I despise the presentation layer: any good GUI-builders for Access applications?
What are some common tools and APIs (unit test frameworks, build automation systems, etc.) that MS Access programmers frequently use?
Any links or resources you would recommend?
It sounds like a pretty simple application: take inputted data, compare it to some tables, and throw some output to the screen. I'm a pretty decent programmer so even though I've never done an Access program before it couldn't be too difficult for me to pick up.
Thanks for any thoughts or suggestions!
Access as a front-end
Well, people feel strongly about Access. The main reason for the negative view is that it is widely used by non developers who have no concept of proper database development and end-up with these barely working, horribly designed applications that bring dread into the heart of developers.
Having said that, Access is nothing more than a Rapid Application Development tool with a very low barrier of entry.
The good and the bad
Access is a fairly old product line, spanning almost 20 years. A lot of people's objections to Access as a technology are grounded in its early history: since backward compatibility is something that Microsoft deems important, Access has retained most of its features, good or bad, over the years.
You can see the choice of VBA, non-winform forms, promotion of modules over OOP, to be bad choices, but the continuity of these early-on design decisions have made Access a stable platform to build on.
VBA: is the language that never dies. It's clunky, outdated, lacks recent advances in languages, but it's also fast, simple to learn, flexible, easy to interop with (for instance calling Win32 APIs is really simple), and it can be interfaced with external libraries (event written in .Net).
Bound forms: by default Access makes it easy to create working applications without a line of code. Most queries can also be created without having to go down to SQL at all. If you're a control freak, it can be annoying, but it's easy to drop down to code and control everything from there.
Third-party integration: even though there are lots of add-ons to Access, I wouldn't recommend using most of the user-controls or third-party libraries unless you really have to. They can be very hard to deploy in environment with limited user rights and versioning can become hairy.
Ribbon: it may be good or bad, depending on who you talk to, but Microsoft has invested a lot into it and it'll probably be there for a while. At least the Ribbon and the improved controls in Access 2007 and later make applications look and behave in a modern way. Gone the horrible UIs of old, you can now do really pretty things with themes, HTML layouts and a modern ribbon.
Reliability
Most of the objections, especially about reliability, are simply no longer true.
A carefully designed Access Application can support dozens of concurrent users. I have a decent-size application managing Procurement/Stock/Quality/Parts/Projects for a manufacturing company that has 150 users, of which usually 50 are connected at any given time. I haven't had any corruption in years.
Of course, you must always bear in mind that Access is a multi-user file-based database, so you cannot expect it to work without risk in environments with unreliable or slow networks, and connecting to a an Access backend through WiFi is really asking for trouble, just like you wouldn't work on large Excel file over wireless either.
Maintenance is part of the lifecycle of an application. Preventive maintenance is extremely important.
Don't wait for something to go wrong: build some admin tools within your app that will help check the state of your data (make sure everything is coherent, detect invalid user inputs, etc).
Also compact the database regularly (I do it nightly after I make a backup as part of the daily automated tasks on the backend server).
Some random tips
Make sure your front-end and back-end are split: only data should be on the backend, and the front end should be installed on each user's machine.
From your front-end, open a permanent link to a dummy table on the database back-end: keeping an always-on connection will greatly improve performance. For the reason why, have a look at this question.
The backend should be in a shallow network share (don't put it deep under multiple directories).
Make sure you think hard about how you will deploy your updates to all clients automatically.
There are many ways to do this. I developed my own but you could use ClickOnce or Tony Toews's Auto-Front-End Updater
Use the Runtime: your front-end application can run without users meddling with its internals if you deploy the Access Runtime on their machine. It's free too.
Don't fight the tool: Access has a certain way of doing things. Just use the tools available without going to code until you have exhausted the capabilities of the RAD environment. You may be surprised by how much you can achieve without any code at all.
Nothing stops you from using OOP: defining classes and binding your classes manually to your forms, controlling data updates, etc. The default behaviour in Access tends to encourage quick-development and is fine for small projects, but if you suspect that your project might grow, plan for the future, just like you would with any other framework.
Access as a backend database
Now, if you want to use a front-end written in something else, say C#, it's fairly easy to use Jet/ACE drivers to connect to an Access back-end database.
Jet is the older driver for Access and only supports .mdb files. 32 bits drivers are installed by default in Windows (still there in Win8) and can always be relied upon.
ACE is the new .accdb format used by Access2007/2010/2013. It has increased limits and enhancements over the older version but it can still talk to an .mdb.
You will have to install the Microsoft Database Engine on all the clients (not necessary if either a full version or the Runtime of Access 2007/2010/2013 is already installed though).
Don't try to use 64bit versions of Access/ACE driver. It's the future but it introduces many new issues, especially if you are using 3rd-party libraries or some of your clients have 32bit Office installed (your can't mix and match 32bit and 64 bit office components).
Similarly, don't build your C++/C#/Java/Python front-end app in 64bit mode and expect the 32 bit ACE driver to work. Keep everything in 32 bit, make things work, then test 64 bits versions if you really need to.
Do always keep at least a single connection open to the back-end database from your code, as mentioned above.
Ideally, try to abstract any Access-specific code to make it easier later in case you need to switch to a server-based database. You could use an ORM that can talk to different back-ends transparently, or you could at least separate your SQL queries into resource files or separate objects that can be easily replaced later.
Depending on the load (mostly how much data need to be changed in the DB), an Access back-end can easily accommodate between 20-100 users without issues. Things will deteriorate if there are lots of insert and updates occurring all the time. There are lots of tricks that can be used to make things better and make Access scale well, but you are inherently limited by the type of application your are building and how users are accessing its data.
I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
I've got to convert a not terribly complicated bespoke project management system from MsAccess Application to PHP/MySQL. I've been programming for donkey's years but embarrassingly know practically nothing about modern methodologies.
So the old 'learning curve' versus 'improved efficiency' conundrum rears its ugly head once again.
Although I've Googled up some stuff I don't want to prejudice your suggestions, where would you start, I'm at your mercy?
What sort of learning curve am I looking at?
Consider learning a PHP framework and its philosophy and architecture to produce the application. You'll be glad you did.
http://www.phpframeworks.com/
Basically, this will help you get up and running quickly with all of the necessary moving parts, in a way that promotes best practices. IMO it's probably the quickest and best way to accomplish your goals.
For recommendations on which one to choose, have a look here:
https://stackoverflow.com/questions/184395/what-is-the-best-free-php-framework-working-on-shared-hosting-and-why
Well, when you say you been writing code for years, do you have any choice as to the final platform?
Access 2010 can create web based applications that scale horizontally in a HUGE way. The resulting applications don't requite Silverlight or even any ActiveX, but ONLY a standard browser. Here is a video of a application I wrote in Access, and note at the half way point I switch to running in a browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
Access 2010 also now does have database triggers and stored procedures. However, you are hinting that you don't have a choice of technologies here so the above new features and even the new Web site creating ability of Access is thus moot for you.
I guess the 1st area I would start with is installing and setting up MySql. The MySql site has some good links to tutorials etc. You simply have to get up to speed with that database server and get conformable with it regardless of learning PHP anyway, so that one step and area I would start out with. And, if you worked with databases, then you find MySql quite easy to get up to speed with so you feel like you making some progress as you embark on this new road