I maintain in-house business software for a living. Technologies included here are Java, Struts, Spring MVC, jsp, wicket, and a few others. I think it's time to branch out and learn something new.
I am hoping to show myself with a side project that writing code can, in fact, be fun (in some plane of the universe), and that I haven't wasted the past few years of my life doing something I can never love or have fun doing.
I'm thinking of having a fantasy-sport style web site - obviously much, much smaller with regards to features and all that. I was hoping I could get some recommendations for the newest or cleanest frameworks that will allow me to accomplish such a project. My goals are to work on following a real development process instead of just hacking a bunch of crap into an already crappy application on a daily basis. Also I will strive to follow best practices and create good, clean, understandable code that I don't shudder at the thought of having to modify. It's hard to do this at work, because the software I work on has already been developed by 50 guys from various continents that never took the time to design anything before jumping into coding.
I would need a simple database to store users and their picks for each event. Also at my job, the login security is all handled by another group completely. Do people usually write their own login systems from scratch, or are there open source utilities for that as well? I'd be interested in those, as my site will need to have a user login system, and be secure.
I had ruby and rails installed on my computer the last time I conjured up the motivation for this idea, but that was nixed by a hard drive crash. I figured before I just jumped straight to rails for this idea, that I would get a few other opinions off stack overflow to see if people liked something else that I didn't know about.
Also, if anyone has any good resources for how to think about OO design, I could brush up on that as well. I'm looking for anything that will help me to just think about the design from the start and how to get my thoughts into a diagram. I'd like it not to focus so much on patterns and other principles as much as just how to get started and actually put my thoughts in a professional document that I can use to build my project from. I tried to practice this prior to a card game that I wrote, and it got way too complicated way too fast, and the results ended up being not so great.
I’m more familiar with Django, although like you, the only frameworks I’ve really used are the Java/Struts/Spring/JSP, etc. The automatically generated administration interface in Django is amazing coming from these, and it comes with its own authentication system too.
Unless you’re especially predisposed against Python, I think you should give it a go.
Ruby on Rails, Python on Django, PHP on (not sure -- maybe Zend? or CakePHP?), are probably the most popular frameworks if I understand correctly that you want to learn a new language. If I misunderstood you, and you'd rather stick with Java, GWT seems pretty cool -- it's the only real way to avoid "explicitly" writing Javascript (if you DO want to learn and use some Javascript, I personally am in love with Dojo, but jQuery is substantially more popular: those are two good popular frameworks you should consider, though there are others of course, like for all languages I mentioned so far).
One advantage of picking Python and Django is that they work particularly well with Google App Engine (and with Dojo, too, thanks to the cool dojango project!) -- GAE supports JVM too, now, but it's supported Python for a much longer time and the Python side of it is more solid and complete at this time. So, if that's the technology stack you choose, you get to develop and deploy for free, on highly scalable infrastructure, at least until your app gets more than a few million page views per month -- and you really minimize your system adminsitration hassles, all you do is basically to code and write one simple configuration file.
Related
My company is planning to build a simulation tool for processing (beverage) and we're currently looking at a half-baked system written in Xojo. I had personally never heard of this language and would appreciate it if anyone could give a quick assessment.
We have no in-house Xojo competence at all and are of course reluctant to bring in a system that would require a big investment in know-how for just one system.
So, we're now looking at our options: Port it to a language we're good at (C# or Java) or continue development in Xojo while building internal skills for the language.
So, what are the big pro's and con's with Xojo?
Cheers
Xojo has been around since the late 1990s, then named RealBasic. Its strength lies in its ability to make native looking and behaving apps for many platforms, mainly OS X but also Win and even Linux. The dev community is fairly small, though. But the company managed to stay in business all this time and isn't looking to end it any time soon.
The language is fairly simple and easy to learn, using long known concepts (its design was based on Visual Basic).
Knowing Java, it should be easy to grasp the language. The bigger hurdle is probably getting familiar with its libary. Many things are much simpler to accomplish in Xojo vs Java, though.
Call me lazy, but that's what I like about Xojo. I also program ObjC in Xcode, but for those little tools that just need to work quickly, Xojo is superior for whipping out a program quickly that that has a decent UI and works on many platforms with little to no tweaks.
If you need x-platform support, give it a try, for sure. If you only need the app to run on a single platform, and if you have skills with other dev systems, I'd advise against starting out with Xojo, to avoid the risks you get when going with such a small company that's offering closed-source software.
In your particular case where you have already a half-working solution, I suggest you take a few days to familiarize yourself to get a feeling for it (you can use Xojo for free as long as you don't build standalone apps with it). It's overall fairly stable and I'm still using a 3-year old version most of the time to develop and build my apps. So, even if Xojo should go out of business suddenly, I'd not be too worried. As long as you stick with the simple functionality (e.g. not use unique features such as XojoScript), you can still convert the app to another language later, but there's also a fair chance you never have to.
If you are looking for someone to take a look at your Xojo project I'd recommend posting on the Xojo Find A Developer page at http://www.xojo.com/support/consultants.php where all Pro developers get it. The consultants that want to talk to you about it will then contact you. (Full disclosure: we, BKeeney Software, are on the list and would be happy to help you figure it all out).
I work in a small organization that has built an enterprise SaaS solution. Up until this point our workflows have had no programmatic interface. We're moving to a model that will allow for an end user to do anything programmatically that can be done in the UI. I'm looking for suggestions in terms of the language/framework that you would use to build that programmatic layer.
From an organizational perspective I would like the current UI team to also have ownership of the API. That team is familiar with PHP, Rails, and Javascript. Our current back-end code is written in Scala. I'm leaning toward not doing the APIs in Scala because it doesn't seem like the right tool for the job and the lack of subject matter expertise around it on the UI team.
From a functionality perspective most of the APIs will be fairly simple database operations (CRUD) with perhaps some simplistic business logic applied on top (search for example).
I'm a bit intrigued by using Node.js for this as everyone on the team is really strong with Javascript. That being said I don't just want to hop on the semi-new technology bandwagon. Because it is enterprise software, unit testing frameworks, reusability, and extendability are all important considerations as well.
Any suggestions?
I realize this question was about technology options, but there's a fundamental concern that seems really important to call out:
From an organizational perspective I would like the current UI team to also have ownership of the API.
While this sounds like a logical approach, it may not work out well unless you're UI team is made up of really solid engineers. SaaS API development is arguably one of the most challenging aspects of modern software design. A great API will make everyone's lives easier, while a poor API will bring your system to its knees and leave you completely clueless as to why.
As a quick example, if you don't solve the end user's needs in the right way, you're likely to force a number of n+1 problems on them (and thus, on you.)
There is a bunch of great material out there about how to design great APIs and even more about the pitfalls of designing a bad one. Generally speaking, most of the UI devs I've worked with, particularly ones that are only familiar with scripting languages, are not people I would entrust to API design. Instead I would utilize them as customers (in a Scrum sense) who guide the design by describing end-user needs.
I faced something like this on a previous project, where we ended up going with a combo of Esper and our own DSL written using ANTLR 3.0. Our biggest concern with using a fully funcional runtime, was sandboxing the user's code.
That said, I think Node.JS would be one of the easier ones to sandbox and it fits your needs. Maybe using something like this: http://gf3.github.com/sandbox/ or looking into Cloud9's code to see how they keep things safe. I also like that with Node.js you could give your users a pretty niffy editor using Ace.
Also check out this post: How to run user-submitted scripts securely in a node.js sandbox?
I spend a lot of time (actually too much time) developping back-office applications whose main purpose is content management and web application configurations. Here is how I can describe these apps :
- Made with PHP
- Using a MySQL or Postgres or SQLite database
- Made of a lot of pages and features
- Very simple features, mostly data CRUD (create+read+update+delete into the database)
- Mostly made of forms
- UIs are usually quite simple (html + css + very basic javascript)
All of the data access code in these apps relies on a library I developped years ago and re-use every time I can. This part is not time-consuming.
What's time-consuming is the UI part, and mostly designing data-lists and forms. Using a WYSIWYG editor would make a lot of sense here, except those I tried (Dreamweaver, Frontpage, Expression, Eclipse, ...) don't really make it much faster, because the generated code is often bloated, and these tools can't rely on custom libraries such as the one I made and use.
I figured using a Web Tookit could be another way to spend less time developping these tools. So before I spend too much time looking for the perfect toolkit, I would appreciate your opinions and experiences on that kind of matter.
Disclaimer : I'm not looking for advices on how MVC is the way to go and how CodeIgniter/Zend/WhatEver is the framework I should use. My question is not about the frameworks or the design patterns I should build my applications upon. My question is about using the right tool to make simple web-applications development faster, and their code even more re-usable.
Is there an awesome web-application RAD tool I don't know about ?
Which toolkit do you use for simple but form-heavy web applications ?
Are there good, light, non-bloated, reliable toolkits written in PHP ?
Thanks in advance !
Edit : Not getting much feedback so far :/ I'm aware that my question is very broad, but I'm sure lots of people work on the same kind of projects I'm talking about, and have improved their productivity by using toolkits such as GWT, Wicket and such. Tell me about it, please :)
September 28 edit : Thanks everyone for the interesting answers. What I'm looking for is not covered by any framework I could try in the past months. PHP is probably not the best language to use for my vision of RAD, but since it's a language I know very well, and since I don't want to spend too much time learning Python as well as I know PHP (for the moment), I decided to do it by myself. Everytime I have a specific need for a widget, I code it in the most re-usable way...so far so good :)
I might open-source that toolkit at some point, and will let you guys know.
The PHP project I've been working on the past few years is a lot like that. Heavy on forms, heavy on server-side logic, but lots of redundant form coding. Too make matters worse, it wasn't all forms, sometimes we actually need to do fancy layout (even just doing a tree control is a pain without a library), and the home-grown nature of the UI meant that I would be battling browser quirks from start to finish.
So, I got to thinking about what a better architecture would be. We needed very powerful form controls, rich grids, rich trees, advanced layout, and we needed to migrate to that gradually. None of the PHP frameworks seemed to fit. Then I took a step back and realized that it didn't have to be PHP, it could be javascript also. We already had a requirement on javascript, so it was fine to go the distance with it. First I looked at the smaller libraries, jquery, prototype, but it became obvious that they didn't do enough. So I looked at Dojo, ExtJS, YUI, all the really heavy javascript toolkits, and settled on ExtJS as having the best controls.
We had a UI structure that relied heavily on iframes, a navigation frame on the outside, application frames inside that, feature frames inside that, and so on. What we ended up with is we're migrating those from the outside in. It's all becoming ExtJS, and it's all living in the same page. The server-side code is kept the same, but it's migrated into web services. At the same time we've integrated zend framework, and are porting some of the stuff you really shouldn't do home-grown to it, like authentication and translation.
The end goal is being able to write just the business logic without having to mess with all the boilerplate. It's too early to know if my approach will pan out, but I think my message would be to be critical towards your code base and decide which parts you want to keep writing yourself, and which parts you want to outsource to a library.
Please try http://agiletoolkit.org/. I think it's what you need. Results with minimum time/code.
At the moment I'm using a solid forms class to render HTML forms with client- and server-side validation, and a database class to write the SQL. I can get a CRUD section of my admin console up in about 10 lines of code. I wrote those classes myself so I can re-use them in all my projects. Hopefully that gives you some ideas?
I would stay away from WYSIWYG tools personally.
I'm testing NuBuilder.com, I discovered it does
within days, at first looks promising. If you take a look
please send me your feedbacks!
Maybe adopt or create an "app-based" infrastructure like Django's? In Django's case, the community has created some powerful baselines like Pinax.
I think Symfony may be the way to go because, like your apps:
it's written in PHP
ORM based on Propel/doctrine (so you can use MySQL, Postgres or SQLite)
Architecture and patterns used will help you with complex applicatons
You'll find tools helping you to debug, document, and test your application
Forms creation, validation, l10n & i18n, testing, AJAX is easy (forms within symfony explained here, check it out)
prototyping you webpages while developing your application is easy
Other tools/practices implemented in the symfony framework that will make your life easy:
full configuration using YAML syntax (easy to read and understand)
the scaffolding feature generates for you a simple CRUD interface for editing your data.
you don't have to worry about coding form sanitization, security, caching, ACL; configuration is needed, but no heavy coding.
The only downside, you need to read some documentation to understand "the symfony way of doing things". But hey, a good framework is 20% code and 80% good practices.
My point is, even if you don't want to use Symfony for your project, you should check its features and built-in tools, because that's the kind of tools you want for your project.
I started using Django and it has very helpful features, esp. the built-in admin (for general CRUD stuff) and really great form-handling code & widget rendering. I'd suggest taking a look, even if you don't plan on using python, just to get an idea.
You mentioned that you don't want advice on "Use X framework", since this is more about RAD & UI/forms than system architecture. But I've found that a good framework helps just as much with the UI & forms side of things as it does the architecture. That means that while frameworks are great for big projects, they're also very helpful in reducing code redundancy. I started creating my own helper functions in PHP that I would copy from app to app that would automatically render an HTML form based on a few parameters. Even after a lot of work, this was very rudimentary compared to what Django offers, and basically I was writing my own framework.
I think you may be looking for a GUI-style tool to help, but you might find that a good PHP framework is more helpful in this case. At the very least, have you tried creating your own helper libraries? I know those helped me a lot.
Simple Example:
function renderInput($name, $value="") {
print "<input type=\"input\" name=\"" . htmlentities($name) . "\" value=\"" . htmlentities($value) . "\" >";
}
function renderRadios($name, $value="", $choices=array()) {
for ($choices as $cvalue) {
print "<input type=\"checkbox\" name=\"" . htmlentities($name) . "\" value=\"" . htmlentities($cvalue) . "\" " . ($cvalue == $value ? "checked" : "") . ">";
}
}
And build up from there. Stupid things like this tend to make form creation just that much faster. A good framework will blow this out of the water. And I'm sure the above has some typos, I haven't done PHP in a little bit.
If this isn't what you're looking for, could you add some more to the question? I'm curious.
Although you're asking for PHP + MySql, I would like to recommend you to give a try to the OutSystems Agile Platform.
You can create a simple CRUD app in less that 10 minutes and grow it as you go to a more complex system.
Download the Community Edition for free at www.outsystems.com.
Best,
Not sure but looks like Tibco General Interface (http://www.generalinterface.org ) is what your looking for.
What do you prefer (from your developer's point of view) when it comes to implement a business process?
A Business Process Management System (BPMS) or just your favorite IDE with the needed tools and frameworks (a reporting tool for example)?
What is from your point of view the greatest Benefit of a BPMS compared to an IDE with your personal tools and frameworks?
OK. Maybe I should be more specific... I got to know one specific BPMS which should make it easy to implement a business process by configuring rules. But for me as a developer it is hard to work with the system. I would like to work with text files which I can refactor and I would like to be able to choose the right technology or framework for the job I have to do. Instead the system forces me to configure.
There are rules where I can use java, but even then I have to stick to the systems editor without intellisense etc.
So this leads me to the answer of my own question - I would like to use the tools I am used to instead of having to learn how to work with a BPMS (at least the one I know) because it limits me more than it helps. The BPMS I know is a framework from which it is hard to escape! At this time, I would prefer a framework like Grail over any BPMS I know.
So maybe the more specific question is: do you feel the same or are there BPMSes which support you in beeing a developer and think like a developer or do most of them force you to do your job a different way?
In my experience the development environments provided by BPMS systems are third rate, unproductive, and practically force you to write hard to maintain, poorly designed code (due to their limitations). Almost all the "features" (UI, integrations, etc) provided by the BPMS system I'm familiar with (the one sold by that company named for its database) were not worth the money we paid.
If you're forced to use BPMS, as a developer, my advice would be to build as much of your application in a conventional development environment, such as Java or .Net, build as little as possible in the BPMS environment itself, and integrate the two. The only things that should go in the BPMS is the minimum to make the business process work.
Not sure what exactly you ask, but the choice BPM vs. plain programming will depend on the requirements. A "business process" is a relatively vague term in software engineering.
Here are a few criterion to evaluate your needs:
complexity of the rules - Are the decisions/rules embodied in your process simple, complicated, configurable, hard-coded?
volatility of the process - How frequently does your process change? Who should be able to make the change?
integration need - Is your process realized using multiple heterogenous services, or is all implemented in the same language?
synchronous/asynchrounous - Is your process "long-running" with the need to handle asynchronous actions?
human tasks - Does your process involves human interaction, with task being assigned/routed to people according to their roles/responsibilities?
monitoring of the process - What is the level of control you want on the existing process instances being executed? Do you need to audit the actions, etc. ?
error handling - Depending on the previous points, how do you plan to deal with errors, or retry of faulty process execution?
Depending on the answer to these questions, you may realize that your process is closer to a simple state chart with a few actions and decisions that can be executed in a sequence, or you may realize that you need something more elaborated, and that you don't want to re-implement all that yourself.
Between plain programming and a full-fledge BPM solution (e.g. Oracle BPM suite which contains BPEL, rule engine, etc.), there are intermediate solutions such as jBPM or Windows Workflow Foundation and probably a lot of others. These intermediate solution are frequently good trade-off.
I have worked with Biztalk in the past and more recently with JBPM. My opinion is biased against BPMs for the following reasons:
Steep learning curve : To make a process work, I have to understand how the system and the editor works. It is hard enough for a developer to understand the system, let alone a business user. The drag and drop and visual representation is a great demo tool. It certainly impresses managers (who ultimately pay for it), but a developer's productivity just drops.
Non developers changing the workflow : I haven't seen one BPM solution do it flawlessly. Though it doesn't look like code, right click on the box and you do have to put some code, otherwise it is not going to work. So you definitely need a developer to do it. The best part is that it is neither developer friendly nor business user friendly, just demo user friendly.
Testablity and refactoring : It is virtually impossible to test drive a BPMS. You do have 'unit test frameworks' advertised, but most of them are hacks and hard to use. Recently I tried the JBPM one; I ended up writing a lot of glue code and fake workflow handlers to make it work. The deal breaker for me though is refactoring. If the business radically changes it's mind about how a business process should look, then good luck re-arranging the boxes, because just re-arranging them won't work, all the variables bound to the boxes also need to be re-arranged. I would prefer the power of the IDE and tests to refactor my business process.
If your application has workflow, then you could try a workflow library (with or without persistent state). It will still manage your workflows without all the bloat that comes with a BPM. If a business user needs to understand the code, then let the business prepare good process flowcharts and translate them into good domain driven code. Use cucumber style acceptance tests to make bring the developers and business together. A BPM is just something that tries to do too many things and ends up doing all those things badly.
BPMS-- a lot of common business case, use case are already implemented. So you just have to know how to use it. For common workflow, you don't even need to write a single line of code, though mostly you would have to write some scripts to cover things that are not yet implemented.
Plain programming-- just use the IDE to hack out the code. The positive side: more control. The negative? A lot of times are spent on rewriting boilerplate code. And you have to maintain them.
So in a nutshell, I would prefer a Business Process Management System. One that I would recommend is ProcessMaker. It features an intuitive process designer that allows you to design workflow with drag and drop. And you can always write trigger to extend the process functionalities. It's open source as well.
Can one learn programming in VB.net using Visual Studio (Winforms stuff) and never learn what a console "hello world" looks like or how, in code, to change which part of the program starts at execution (and other basic things like that) and still be a successful VB.net programmer? Or are there roadblocks just waiting there to be hit?
Successful? Probably.
Good? No.
I'm sure you can, but I don't think it's a good idea. You'd probably pick up the core ideas through trial and error - but you may well end up with plenty of misconceptions, and you'll probably waste a lot of time in that trial and error phase.
I'd thoroughly recommend learning core concepts first. Apart from anything else, UI development is full of its own little foibles - if you don't know the core stuff to start with, you won't know whether you've hit a UI gotcha or whether your core knowledge is lacking.
Depends on what you are doing with the programs. If you are just programming little tools for yourself to use, then there is probably no harm. For hobby projects you can know as little as you want. However, if you are programming as a job, you should have a much better grasp at what is going on. You may be able to fake your way through for a while, but eventually somebody is going to ask you to do something that should be simple, but because of your limited knowledge of programming is utterly impossible. Then you will know why you have to know the basics.
That being said, there's a lot of programmers out there in the real world with exactly that level of knowledge who do have jobs. Personally, I think it's a bad idea, but you can't argue with the market. If these people have jobs, there must be a real market need for this type of programmer. Kind of goes along with what Welbog said. You can be successful in that you can hold down a job. But you still won't be a good programmer.
It depends what you mean by success really.
It's entirely possible to write a decent winforms application without writing console apps and without changing the starting form from the default.
When it comes to crafting well written applications in a professional way, you're likely to find requirements that mean using a boot strapper (which will control the initial flow) so at that point you'll definitely need to do some research.