I won't be building it in 1 weekend, I was going to use a few days to go through that tutorial and any other resources that seemed up to date with positive feedback from the community. I have about 3 weeks to build the system and the idea of what the site does isn't really complex.

At the end of the day, what is something like that really doing? You have x number of resources with user accounts and permissions that are rendered using standard CRUD templates. That's it really.

Something like that can be done in Express, Sinatra or Rails in probably a day if you hacked it up.

The complexity is tying everything together so that the 10 cherry picked libraries you chose act as a fluent framework. From what I've seen rails already gives you that for free.

lmk how it goes, i'll be curious. 3 weeks seems very short to me, especially with no rails or ruby experience.

If I was creating a program for people with unknown background, I'd probably reach for Python first. More people know the language and it is very easy to learn if they don't.

Ruby is very simple as well.

Also, my angularjs site is coming along nicely. It's way more fun to have a sweet design implemented than some boilerplate BS (or no css at all). Makes it feel much closer to finished.

What movie is that from? I don't get the reference.

Since the thing I'm making isn't for myself I can't wire up my own custom framework in Express and ship it to people. It would be a mistake on my end I think. For personal use cases I don't need to make everything exposed through a unified API because I know how it works on the inside.

If I stick to something that's standard in the industry and well tested / has success out in the wild I think it's a much safer bet for me. All I have to do now is build it out and give a short summary of how things work to the people using it and if they get hung up on something technical I can just point them to the rails documentation.

The alternative would require writing too much documentation or making too many screencasts explaining everything. I would be spending most of my time making a system that already solves these problems instead of just concentrating on the app's features.

Even the author of Express feels the same way. There's some Twitter post where he's like "so many people want to recreate rails in node. If you want something like rails just use it."

I completely agree with Shoe on this and if his site isn't too crazy 3 weeks should be enough time to get it done.

I finally see the appeal to these frameworks though. I think it's kind of interesting that I am coming at it from the other side.

Most people instantly flock to some framework in whatever language (rails, django, couple of the popular PHP ones) and then maybe after a while they move to things like express/sinatra/flask/whatever. I went the opposite route and went from no framework PHP spaghetti garbage to node with express.

I honestly feel like those people will go back to their frameworks after they've spent enough time without them. The sheer amount of crap I had to learn just to get something that was reasonably scalable (not runtime speed but being able to maintain it) was off the wall.

If I spent all of that time just building the applications I wanted to build I would be in so much better shape. At the end of the day that's all I care about. I want to be able to write application-level code and be able to test any bit of the code base without it being a hassle. I don't give a crap about anything else.

My only real concern with rails will be run time performance. I really don't know what to expect on a low end server. I know node/express is quite solid though. It barely uses any ram and can easily pump out 400-500 reqs/s on a 512mb VM with 1 cpu core with hits to a database, sessions and everything you would expect in a typical app with up to 750-800 concurrent connections with reasonable latency given the machine.

i'm surprised you think this. a production ready CMS, with good unit tests, starting from scratch having never learned ruby or rails? i mean i think you could do it, but you'll be doing a lot of stuff badly.

what's going on here? next thing you'll be advocating jquery....

Unit testing in rails didn't seem too bad. For fun I even strayed from the tutorial and instead of using rspec I decided to use the built in unit testing package that comes with rails. Things just worked. It took like 2 minutes of Googling to figure out how to test the value of a selector and the response body.

Setting something like that up without a framework would have been an entire afternoon of research most likely and the end result would be really annoying to use.

Also I'll never advocate jquery in its current form but I don't have any problems with something like angular. It might be an opinion but I see angular as solving a real problem in a way that makes reasonable trade offs.

No, you'd use prebuilt gems. You don't need a framework to do that. It's the exact same process of googling for an example. Only difference is you install a new gem yourself and understand your dependencies explicitly. Honestly I thought the npm ecosystem was very robust as well, and has prebuilt packages for almost everything Ruby has gems for. But I haven't used it much so I don't know for sure...

TV show. Once Upon a Time. Dude's catchphrase is "magic always comes with a price" ... yeah far fetched :P

haha, v nice

@clown,
Magic does come with a price but so does learning how to do the trick.

Finding the gems or modules isn't the painful part.

There are plenty of testing libs in node. Mocha with "should" is most similar to rspec if you like that sort of testing. It would take about 15 seconds to install it em.

But now you have to install another module to abstract away the huge annoyance it is to test a route. So now you would have to install something like supertest which is another lib that lets you test a server. Now inside of your test file you have to require in your app.

It's stuff like this that is just annoying. I don't care about any of this, all I want to do is test to see if '/foo' works.

[incoming wall of text]

In Node's case there's a very productive guy TJ Holowaychuk. Awesome guy, and he's made hundreds of modules. You could spend an entire day going over his github repo page and hand picking modules out to do certain tasks.

He has some of the most popular modules in the node community:

- jade for templating (similar to haml)
- mocha for testing (similar to rspec)
- stylus for css preprocessing (similar to sass)
- express for mapping routes to views and making the request/response cycle just nicer to work with (similar to sinatra but better obviously!)

The missing link would be some type of model and it depends on what you want to use as your database. Mongo is popular in the node community because the API is very natural to use for JS developers.

So you could write your own little wrapper that ties in some type of validation and maybe some base model code that you could use for resources so you don't have to repeat the same thing all the time.

Then finally you could use something like grunt to manage your asset pipeline and do any other tasks you see fit.

Ok cool, so after you hand picked all of that stuff now you have the bits and pieces required to roll your own framework. So the fun stuff begins...

You have an empty folder and it's on you to determine how to structure it. After enough time you figure out you want to do it some way. That's cool, that's the most trivial piece of the entire puzzle.

Next step is wiring up all of your libs to just work together in a way that's not ******ed. That means you would have some db module and you will be passing it around as a dependency to your routes, and you would repeat this for anything else you need (maybe socket.io, etc..). You would also need a reasonable way to handle many configuration settings and environments.

Forget about generators though because writing a robust generator is actually really hard and to make one that's actually useful is close to impossible without having massive opinions. So any benefits of being able to swap in/out components from your rigged frameworks are gone because generating jade templates when you might want to swap in handlebars is going to break things.

After all this you have something that's functional hopefully. So you want to do something as simple as adding in a "photo" resource. So you wire up all of the route end points and you realize after doing this 10 times that you're repeating yourself so much that you decide to just write or find some type of resource lib.

Add this to your dependency list. Now you're dealing with so much code written by random people. It's sheer luck that TJ wrote most of it for node and there's a serious bus factor... if he decided to just not write node code anymore almost the entire node web app community would be ****ed. Most of his projects have 99%+ contributions by him alone.

Maybe after a few dozen or hundreds of hours you have something that works for you and is pretty solid. At this stage the thing is just some type of beast that was composed of a dozen moving parts, it's not really a fluid framework.

It would take a lot of effort to put it all together in a nice way but there's no real gain other than the knowledge you've obtained by doing it all. In the end you just recreate what rails already gives you from day 1.

--

A lot of people like this style of development because they feel like they are in control (because they are), and somehow think it's less complicated but the reality of the situation is it's not less complicated. It's a lot more complicated.

I went down the above path and did learn a good amount of information but all it taught me in the end was if I want to get stuff done I should probably use something that people smarter than me developed and has a roaring community behind it.

It's all well and good when what you want to do fits right into the out of the box stuff. But I found that I was constantly having to hack around in rails to do things, that the testing was ridiculously slow because of the framework overhead, and so I ended up spending tons of time researching how to break into some abstraction so I could figure out how to do what I want, when the reality was that I was doing something very simple that would have taken 2 minutes to figure out if I didn't have to move through the bog of the framework. The reality was that the dream of simple of plug and play that rails advertises just did not match with my experience. Again, ymmv. I would bet though that you'll find stuff that really annoys you pretty fast.

EDIT: btw, there's a framework called padrino that strikes a decent balance between the bloat of rails and the simplicity of sinatra. i might use that if i were working on a project like yours.

Testing was very slow in rails until they set you up with guard and spork in the tutorial and now it's close enough to instant that it doesn't bother me. Have you looked into using those solutions or something else that has the same effect?

What problems did you encounter that you couldn't get around with hacking around it? How long ago did you use rails, is it possible some of the issued you have were changed in later versions?

I skimmed the Padrino web site and it looks ok. I'm not sure I'll switch to it before even finishing that rails tutorial book but I'll look into it more closely before I start the project. There's about 3 different frameworks in Node who try to do what Padrino is doing (minus the free admin), but none of them have any real traction or they impose opinions that are just not a good idea.

I was using it a little more than a year ago, so it's certainly possible it's improved.

I can't remember which but one of those testing utilities didn't work on windows cause of no forking, so then I installed a linux VM just to have better testing, and then it was still slow. Finally I watched a video from some rails expert who was giving this presentation which was essentially how to hack around and create speedy tests in rails. It involved creating another layer of objects sitting on top of your ORM objects (which in itself is fine and you should probably be doing anyway so that your domain objects are a separate entity, but no one developing in rails even knows that there's such a thing as a domain object that's not an AR object, so it's still a huge hack within that framework). Anyway I was like, why the **** is that not just built in? This framework prides itself on being TDD and all, but testing in it is the heavweight pia. That's insane. In order to use the framework properly I have to start learning all these secret hacks that are divulged in conference videos? Anyway around that point I gave up. I don't remember the other specific problems I ran into. I just know I was disillusioned.

Public domain bro

According to the wiki it's not clear cut whether it is or not, better safe than sorry...

Ok cool I thought you were going to say you had an application related problem.

To get super fasting testing at the moment required to just install some gem and that was basically it. The documentation required the other step which was copy/pasting some snippet of code into a test helper file.

It was introduced early on in this tutorial and was painless. The result was having a solution that runs tests in a few milliseconds instead of 5+ seconds to spin up rails and were ran automatically when you changed any test file (this was optional, but seemed useful to have).

http://en.wikipedia.org/wiki/Happy_B...pyright_status

EDIT: AFAIK there is a class-action lawsuit in progress that hasn't yet been resolved

spring/zeus make rails testing basically instant even on huge bloated apps

hmm pushstate is surprisingly easy to implement.

Anyone here but but me think that CRM software sucks ass? At my new job, I'm working with yet another half-baked solution, and its plain shocking how bad it is. I thought the tools from my last job were bad, but this one is just awful.

So basically, I have to send over dailies and to do that, I'll have to export to CSV, normalize, fix manually fix the numbers (write macros), and I'll probably have to build another database to track sales history, and etc.

I've come to the conclusion that these CRMs are little more than half-ass spreadsheets with a fancy skin.

Thinking about it, these programs are all perfectly square pegs and no company is shaped to fit in said peg, and that, in my opinion, exposes the solution. I'm probably going to have to build a similar program at my next job, and my next, and my next.

It makes me wonder if there is a viable market for an open-source CRM software. Suppose there is a basic framework. The software can be fine tuned to the company, and the analysts would have access to raw select queries. A company could hire on there own in house programmer to customize the product, or the company could contact the CRM house to customize it. The company would have exposure to the API so they can have software that changes with their needs.

Then add in some stat and visualization software and there are tons of tools that can at least do what upper management asks for on a regular basis.