I don't understand the significance of something like rails, codeigniter, etc. and scaffolding. From what I read, and maybe it's just wrong, scaffolding isn't used in the production environment. I don't know what it's for. It's neat but I don't know what I am supposed to do with it.
Thanks.
You use Scaffolding to get some results rapdily, for instance to quickly whip out an early protoype or to get functionality like CRUD in place. Usually the code generated through scaffolding is a crutch you have to replace or extend later with something more sophisticated.
So yes, you are right. It's a temporal solution, a stand-in, unless you get the real thing in place.
In that sense, scaffolding is a Technical Debt.
Scaffolding is there for you to "get started", with respect to the features and typical operations of the framework. That said, most of the time, the scaffolding has become outdated and just touches upon the basic features.
It's excellent to see how you're expected to use the application. I like to run a scaffold in a test application to get a look at how the default case is handled. Gordon is correct, however, that it does incur future maintenance time.
Related
Does anybody have any experience with as3-spod?
I downloaded the source code from github and as3-signals and started to try it out, but I´ll take ages to get to know the framework by trial and error and probably miss a lot of best practices. The framework looks good but lack's on examples. The git page does't have a lot of info on that...
If anybody knows some other ORM for AIR that I can use on pure AS3 projects that have any bit of documentation, I´m more than thankful!
I was hoping to do a question-comment asking for clarification, but I don't have enough reputation yet! So I will answer as best I may.
I am using as3-spod for my application. It's been pretty reliable and mostly given me what I want. It's not really ideal, though. What I'd really like is something more ActiveRecord-like, or something original that lets you generate queries by concatenating conditions in a fluid syntax.
But if you're not using Flex (as I'm not, and you're not) then your options are pretty thin, as most of the other AS3 ORMs out there rely on some part of the Flex framework. Apart from as3-spod, the only possibility I could find was Christophe Coenraets' proof-of-concept but as he points out, it would need a lot of work to develop it into a fully-fledged ORM:
This is still a simplistic proof of concept and is by no means a production ready ORM solution.
And I haven't had time for that.
You are right that as3-spod is quite poorly documented. I guess the main class you want to look at is SpodTable. It's from that one you do inserts, selects, etc. An update on a single object can be done from the object itself. Look out for the various signals on SpodTable (select, selectAll, etc). To get going with it, just mark up a model class with metadata, then from your SpodDatabase instance call createTable(MyModelClass).
My main gripes with as3-spod are these (I'm listing them so you don't look for features that don't exist, which I wasted a fair bit of time doing!):
It works asynchronously. Doesn't matter if your actual SQLConnection has been opened synchronously or asynchronously; you have to listen to signals. That means you can't retrieve records and then use them straight away in the same method, you have to listen to signals. What I tend to do is to do large selects when the app starts, then filter the data in memory rather than doing complex queries. Pretty annoying.
Be careful with null values for numeric columns. I can't see a way of setting NULL or NOT NULL for columns using as3-spod; it always seems to make them NOT NULL, which will cause errors if you try to insert a row from an object with null fields.
There's no migration system (a la Rails). I am working on rolling my own as that's an essential feature for my purposes (it's a mobile app I'm developing).
Good luck! Let me know in comments if there's anything else specific you'd like me to cover and I can expand this answer.
EDIT
I've just noticed the existence of AS3SQLite. Haven't used it yet but, looks like there are other possibilities out there :)
Standard way of working on new API (library, class, whatever) usually looks like this:
you think about what methods would API user need
you implement API that you suspect user will need
So basically you trying to guess what your API should look like. It very often leads to over engineering stuff, huge APIs that you think user will need and it is very possible that great part of your code won't be used at all.
Some time ago, maybe few years even, I read some article that promoted writing client code first. I don't remember where I found it but author pointed out several advantages like better understanding how API will be used, what it should provide and what is basically obsolete. I think idea was that it goes along with SCRUM methodology and user stories but on implementation level.
Just out of curiosity for my latest private project I started not with actual API (some kind of toolkit library) but with client code that would use this API. Of course my code is all in red because classes, methods and properties does not exist and I can forget about help from intellisense but what I noticed is that after few days of coding my application "has" all basic functionalities and my library API "is" a lot smaller than I imagined when starting a project.
I don't say that if somebody took my library and started using it it wouldn't lack some features but I think it helped me to realize that my idea of this API was somewhat flawed because I usually try to cover all bases and provide methods "just in case". And sometimes it bites me badly because I made some stupid mistake in basic functions being more focused on code that somebody maybe would need.
So what I would like to ask you do you ever tried this approach when needed to create a new API and did it helped you? Is it some recognized technique that has a name?
So basically you're trying to guess what your API should look like.
And that's the biggest problem with designing anything this way: there should be no (well, minimal) guesswork in software design. Designing an API based on assumptions rather than actual information is dangerous, for several reasons:
It's directly counter to the principle of YAGNI: in order to get anything done, you have to assume what the user is going to need, with no information to back up those assumptions.
When you're done, and you finally get around to using your API, you'll invariably find that it sucks to use (poor user experience), because you weren't thinking about how the library is used (UX), you were thinking about what the library must do (features).
An API, by definition, is an interface for users (i.e., developers). Designing as anything else just makes for a bad design, without fail.
Writing sample code is like designing a GUI before writing the backend: a Good Thing. It forces you to think about user experience and practical effects of design decisions without getting bogged down in useless theorising and assumption.
And contrary to Gabriel's answer, this is not bottom-up design: it's top-down. Rather than design the concrete backend of your library and then force an abstract interface on top of it, you first design the interface and then worry about the implementation.
Generally speaking, the idea of designing the concrete first and abstracting from that afterwards is called bottom-up design. Test Driven Development uses similar principle to what you describe to support better design. Firstly you write a test, which is an use of code you are going to write afterwards. It is important to proceed stepwise, because you have to proove the API is implementable. IMportant part of each part is refactoring - this allows you design more concise API and reuse parts of your code.
I learnt swing basics and event handling basics from head first java...
Then i read a few tutorials on swing app development using netbeans...
and i loved it as i don't have to care about layouts and stuff...
But i read in one of the forums, that i should learn swings properly rather than using netbeans directly...
This confused me a bit....
Please suggest the best way to master development of swing apps....
thanks in advance
Well, I see I'm going to run counter to the majority here ;-)
Hand coding GUIs is a pain in the ass. Anything that makes that task easier is a good thing in my book. When you're just starting, having a generated GUI lets you get up and running faster.
GUI builders handle the really repetitive work and prevent you from doing the most common dumb things. The downside is that same approach will also prevent you from doing the really clever things. Eventually, you will encounter something that you cannot do through the GUI builder and you will need to poke into the code. So, you can't treat code generators like black boxes where you don't need to know what magic happens inside. At minimum, you need white boxes. Let the GUI builder do its magic, but understand that magic and its limitations.
Practice by generating a very simple GUI. Walk through the code and understand what it does. Make a change through the builder and see how the generated code changes. Try changing the code yourself to confirm you understanding is correct. *
If you don't understand something, hit the JavaDocs, the Swing Trail, or browse through the Java2S Swing Tutorials.
If you're still stuck try the kind folks at Java Ranch, or here on StackOverflow.
* Netbeans puts the generated code in guarded blocks and will not let you edit them directly. However, you can open the file in another editor to test a change. Also, you can do quite a lot to influence the code generation using the code tab in the properties window.
It depends on what you see as your goal.
There is no "perfect" approach to get comfortable using Java and swing, it always depends on what you want the outcome to be like.
Most enterprises depend on stability and speed, programmers need to write code fast and stable. If you write complex interfaces by hand it gets ugly when it comes to speed and precision at the same time. You can never write better code in terms of "it is working" then the netbeans gui builder can. Also, no one will probably have a look at your code once the application is up and running.
If you want to get to know swing only for the purpose of knowing it with no deeper intention what so ever, I'd recommend learning it by heart without netbeans as you'll probably familiarize yourself with most of it's functionality quicker then the other way around.
On one hand, if I want to learn something, I want to learn it from scratch, so I would probably go with writing swing-code myself and in the end using netbeans to generate it when I am fully able to comprehend what is generated.
On the other hand, if I need to write applications quick and am not paid to go into any details, I'd simply use netbeans.
I think you have answered yourself... you want to master development of swing apps...
everything that you do by autogenerating without knowing why or how is not mastering in my opinion ;)
If you want to be master, then you should at least know how to do it with your bare hands. Moreover, it will also help you if you will use other gui toolkits (main principles of gui toolkits are more or less the same, imho).
I'm using an MVC framework to develop a web site, I've to care about the design in the sense of look and feel (views) and the code (models, controllers).
I don't know what is the best way to proceed:
code and design iteratively by small chunks?
design first ?
you've got the point
I suggest you design first - it can be a rough design with a pencil/paper but it will give you an idea of what information should go on the page in what manner. This will help you with your views and controller logic. Dont' worry too much about colours at this point.
I always feel it is better to do things iteratively. Design a page or two, construct the model and controller relative to that page, and repeat for other pages.
Sometimes if you spend too long in your models and controllers and neglect your views, you'll end up doing way more or way less than what you need.
The 37 Signals (the source or Ruby on Rails and some really cool web apps) book Getting Real advocates working from the interface down. It gives you a better sense of how the site will be used before you do too much back end implementation.
Here is the specific chapter: From ideas to implementation.
PS: Read the whole book, it's brief and a really good overall philosophy for building things the way they should be build. And no I am not affiliated with them in any way.
One small, but very good tip I got, was to work out what kind of 'friendly' URL's you would like to see in your site. This in turn leads you to what routes your require, which in turn gives you an idea of the controllers and actions you will have to create.
It depends but there are several rules of thumb:
the bigger the project the more it benefits from the design first, design well approach.
if there's inter-dependence between the elements of the project - such as lots of foreign keys in the database - you are better off at the very least designing everything around those inter-dependencies, or you're gonna regret it later
MVC frameworks enforce some design decisions by their very nature, so use that to help you
beyond a certain size - say more than a week's work - it's an absolute necessity. Same goes if it's a team effort
In your particular case, since I'm not sure about the project size, I'd suggest having your schema designed ahead based on your needs, which will tell you about dependencies, and then do the iterative thing, starting with the dependencies.
If you have specific APIs you have in mind, it's a good idea to design around those as well
The beauty of MVC frameworks is it simply does not matter.
Obviously you'll need some vision to work to, but it's up to yourself. I'm a strong believer in iterative development. In this case you'd create a section of the site, views, models and so forth. Once that was working, move to the next section/feature of the site.
The both ways are OK but it would be better if you have a designed view (even a mock up) so you can know what data to get how to format it when you develop you model and controllers
My suggestion which will save you a lot of time and headache is start off with design.
You have two designs here. One is the UI (interface) design. All the visuals etc.
When you have a UI design you will know how to create your mark-up from the get go without having to do the work twice after you've completed a design.
The other is the software design. the MVC framework helps a lot with this but you also don't want to just start coding without having a plan. You'll find yourself back tracking a lot and recoding stuff you've already done that way.
An iterative approach is the way to go. I might suggest spending time on the model and getting it solidified first. Then, iterate through your controllers and views. This will help validate what you've done in the model, and bring up any glaring issues that need to be addressed sooner vs. later.
I, as most here would say design (at least to a extent) first.
I would wireframe interactions (these can, and should be be refined later) and, perhaps most important, (at least if it's a traditional web site you're working on) plan the architecture, map the structure of the site you're working on (the Information Architecture part). In order to get an overview of the site and know map out user paths through the content.
That's at least my 'modus operandi' for web sites if I'm working alone on them.
(I mostly work in a UX team so my professional workflow is more in the design part than production coding nowadays)
Understanding the Requirements
Database Design
User Interface Design
Business Logic Design
From my experience I would say you should always plan first. (I even plan my planning phase).
I assume you’re doing something like a GUI wired up via .aspx using the MVC model, maybe even the Entity Framework?
Web development like this can very easily get complicated once you start to build it up.
It is important that before you do anything you know exactly what it is that you are trying to do, this way you know when you are undershooting or overshooting your goals and whether or not the code you are writing actually fulfils the requirements.
There are many models which you can base your project development on, all of which loosely follow a sensible System Development Life Cycle in one way or another.
If you haven’t read up on the different development methodologies, here’s a site that will give you a good overview : http://www.itinfo.am/eng/software-development-methodologies/
I'm toying with the idea of phasing in an ORM into an application I support. The app is not very structured with no unit tests. So any change will be risky. I'm obviously concerned that I've got a good enough reason to change. The idea is that there will be less boiler plate code for data access and there for greater productivity.
Do this ring true with your experiences?
Is it possible or even a good idea to phase it in?
What are the downsides of an ORM?
I would strongly recommend getting a copy of Michael Feather's book Working Effectively With Legacy Code (by "Legacy Code" Feathers means any system that isn't adequately covered by unit tests). It is full of good ideas which should help you with your refactoring and phasing in of best practices.
Sure, you could phase in the introduction of an ORM, initially using it for accessing some subset of your domain model. And yes, I have found that use of an ORM speeds up development time - this is one of the key benefits and I certainly don't miss the days when I used to laboriously hand-craft data access layers.
Downsides of ORM - from experience, there is inevitably a bit of a learning curve in getting to grips with the concepts, configuration and idiosyncracies of the chosen ORM solution.
Edit: corrected author's name
The "Robert C Martin" book, which was actually written by Michael Feathers ("Uncle Bob" is, it seems, a brand name these days!) is a must.
It's near-impossible - not to mention insanely time-consuming - to put unit tests into an application not developed with them. The code just won't be amenable.
But that's not a problem. Refactoring is about changing design without changing function (I hope I haven't corrupted the meaning too badly there) so you can work in a much broader fashion.
Start out with big chunks. Set up a repeatable execution, and capture what happens as the expected result for subsequent executions. Now you have your app, or part of it at least, under test. Not a very good or comprehensive test, sure, but it's a start and things can only get better from there.
Now you can start to refactor. You want to start extracting your data access code so that it can be replaced with ORM functionality without disturbing too much. Test often: with legacy apps you'll be surprised what breaks; cohesion and coupling are seldom what they might be.
I'd also consider looking at Martin Fowler's Refactoring, which is, obviously enough, the definitive work on the process.
I work on a large ASP.net application where we recently started to use NHibernate. We moved a large number of domain objects that we had been persisting manually to Sql Server over to NHibernate instead. It simplified things quite a bit and made it much easier to change things over time. We're glad we made the changes and are using NHibernate where appropriate for a lot of our new work.
I heard that TypeMock is often being used to refactor legacy code.
I seriously think introducing ORM into a legacy application is calling for trouble (and might be the same amount of trouble as a complete rewrite).
Other than that, ORM is a great way to go, and should definitely by considered.
The rule for refactoring is. Do unit tests.
So maybe first you should place some unittests at least for the core/major things.
The ORM should be designed for decreasing boilerplate code. The time/trouble vs. ROI to be enterprisy is up to you to estimate :)
Unless your code is already architectured to allow for "hot swapping" of your model layer backend, changing it in any way will always be extremely risky.
Trying to build a safety net of unit tests on poorly architected code isn't going to guarantee success, only make you feel safer about changing it.
So, unless you have a strong business case for taking on the risks involved it's probably best to leave well enough alone.