Ruby on Rails + Flash Application ?

and if you ask a boss or customer what is that

they prefer, pretty vs. working code, I can tell you that not 100 but

200% of them will choose working. :wink:

I donā€™t give my clients that choice. They get properly designed code

that works. Itā€™s not up to the client to make technical decisions.

I agree with this sooo much! However, if the client is large enough itā€™s very easy/tempting to just do as they askā€¦

Cheers,

Andy

Erroneous. You're not giving them all the information needed to make their choice.

Sure, quick and dirty can have its place; but by using it you're introducing Technical Debt [1], which in the long run can cost them an awful lot more than had the code been written in a well-designed fashion in the first place. It's not a cut 'n dried choice between pretty and working (and trust me, I've had to wade through ugly and broken enough times)... it's much more complicated than that, and needs to be presented to decision makers as such. The only way I use if people want a simple choice is to say there are three options: Ā Ā * quickly produced Ā Ā * well written Ā Ā * cheap price ... then give them an option to pick which two (and they can *only* have two) of the three they want.

This makes it clear, that if they choose Quick and Cheap, they will not be getting Good.

Returning to the technical debt argument; I've seen this in practice many times. It's certainly frustrating when boss/customer ignores sense and goes for short-term gain... but there is always the option of working for other bosses/customers :slight_smile:

[1] Technical debt - Wikipedia

Michael Pavling wrote:

  * quickly produced   * well written   * cheap price ... then give them an option to pick which two (and they can *only* have two) of the three they want.

This is close, but the most useful variable was left out of this list.

The choices are actually: 1. Time 2. Quality 3. Cost 4. Scope

Stakeholders are given their choice of three and development controls the forth. I only mention this because scope is actually the most "sensitive" of the four variables.

Quality is relatively ineffective at controlling the other three, yet at the same time can profoundly affect the other three. In other words you can't really "buy" time by lowering quality. Lowering quality in an effort to reduce time will likely have the opposite effect. Code of poor quality, in the long run, takes longer to write than quality code.

Time in many situations is fairly fixed. The product needs to ship within some reasonable "budgeted" time scale. Hence time can also be an ineffective control variable.

Cost is a somewhat tricky control variable. In some situations it can effectively control the other three, but in other cases it is essentially fixed, and as such can't be used reliably for controlling the other three variables. Throwing more resources (programmers) at project in trouble does not guarantee success.

Scope can often be the real key control variable for a large percentage of projects. Scope can "buy" you time. Often building less (at first) can deliver a working product, meeting or exceeding quality requirements, within the budget of time and cost. This is the core principal of agile software design methodologies. The feedback gained from early, small, releases will also have a profound impact on all four of these variables.

Marnen Laibow-Koser wrote:

As I'm developing on Windows, remarks concerning Objective-C, Cocoa, putting Cappuccino at the same sentence.. make me think this is not the things for me right now even if I wanted to (wish it was)..

Then you completely misunderstood. Cappuccino is a JavaScript framework inspired by Obj-C. There's nothing OS-specific in it AFAIK. Really, take the initiative and do some research!

Precisely correct. Cappuccino/Obj-J was designed by and for Obj-C/Cocoa developers to be as much like developing Cocoa-like applications that run in a web browser on top of JavaScript. The only requirement is a web browser that has a reasonably modern JavaScript engine. That pretty much covers all current releases of web browsers on any and all platforms.

I really only mentioned it, because it's the choice I would make, and that it does demonstrate the power and flexibility of the JavaScript language.

Check out this demo to see just how "desktop-like" Cappuccino applications really can be: http://280slides.com/Editor/

Keep in mind that this application is entirely web standards compliant.

Not sure about SproutCore.. I understand the pros and cons of using Flex/ Flash, though was nice to hear there are developers out there who do use it (on windows), in case I do follow this direction... After better understanding the suggestions, my tendency (or wish at least) is to follow tools / technologies which will make my app more likely to be accessible on most platform / following Standards- compliant HTML..

I think that's a good choice. But that shouldn't be surprising. :slight_smile:

I believe SproutCore is an excellent choice for most web developers. It can still produce really desktop-like applications that run on top of JavaScript, but still be somewhat friendly to web style development. Whereas Cappuccino "feels" nothing like web application development.

The first "app" you wrote was it "perfect"? mine wasn't. We've all gotten where we are from writing code and learning best practices. Sometimes we have to just jump in and get it done. I don't like doing that, but sometimes you have to. If all I did was read tutorials and best practices, I'd never write any code. In three years we will look at code and say "Why was this written in XHTML and not HTML5? What were they thinking?"

look at these sites (I did not make these!)

http://www.yvettesbridalformal.com/ really?!?

Most people, read: non-programmers, don't care about the code. We do. We care how it's created. Learning Rails, which means learning some Ruby and OOP too, is quite a bit. Learning Flex on top of it is a lot to chew, in my opinion. It can be done.

Again the Flexible Rails Ā Ā Flex 3 on Rails 2 Ā Ā Flexible Rails

What it sounds like you're wanting to do is a good choice. it walks you through of setting everything up. It uses Flex 3 and Rails 2. It creates a "wonderful" to-do list. but you'll get the jist on how to get Flex and Rails to talk to each other.

Also have you checked out any flex groups? There should be tips there too. This one is based in Dallas TX http://groups.google.com/group/d-flexorg

Cheers, John

True, we all have to start somewhere.

However, my first few projects, or should I say failed experiments, never went out to paying customers. Thereā€™s no reason any customer should pay for the inexperience of the developer, whether thatā€™s in short term (everything taking a lot more time than needed) or in the long term (plenty of obscure bugs due to no testing, bad code and no easy way to add functionality to the app in question).

My first few Rails projects were internal use apps, and yes, I learned a lot from them, but Iā€™m very happy they never went outside of the company :slight_smile: They are good for one thing though: when I do a seminar for students or beginning web developers, I like to pick out some examples from that old code to show how it SHOULDNā€™T be done :slight_smile:

When I said database-backed web development is quite challenging, I was talking about the sheer number of languages and environments you have to feel comfortable with to produce a good product: database structures, a feel for good design, HTML, CSS, JavaScript, Ruby, Rails, OO programming. Bringing something like Flash into the equation replaces HTML, CSS and Javascript with Flash and ActionScript, but imo makes implementing the backend harder. I know Iā€™m better off now and enjoy what Iā€™m doing, but developing desktop applications was easier in many ways (and awfully annoying in other ways, but still), especially when it comes to one IDE with a GUI design environment etc. Whether Flash is a good way to go or not is up to the original poster, but unless heā€™s very experienced with Flash (and I donā€™t mean the timeline, tweening and transforming objects etc) and especially ActionScript, I would seriously advise against it. It may be easy to throw together some Flex interface, but thereā€™s still a lot to do behind the scenes thatā€™s actually just as hard as going for a plugin-less solution.

Best regards

Peter De Berdt

Peter De Berdt wrote:

However, my first few projects, or should I say failed experiments, never went out to paying customers. There's no reason any customer should pay for the inexperience of the developer, whether that's in short term (everything taking a lot more time than needed) or in the long term (plenty of obscure bugs due to no testing, bad code and no easy way to add functionality to the app in question).

I don't entirely agree with this. Unless you're just creating "cookie-cutter" style applications that can be completely predicted up-front, the customer IS paying for the inexperience of the developer. Nearly every application I've built in my long development career has required learning something new, something I'm inexperienced with. Whether that be related to the problem domain the software targets, or the technologies required to produce the desired result.

As software developers we are as much researchers as we are developers. Matching the right technologies to solve a problem is a major part of what we do. Often the "right" technology is something we are not currently familiar with. What distinguishes great developers is the ability, and willingness, to take on new challenges, and new technologies as they present themselves.

If learning a new technology is part of providing my customer with the best fit solution, you bet I'm going to charge them for that.