We need CI on Heroku for our RoR app.
We want to use an add-on. I don't mind paying a few bucks to avoid complexity / distraction.
I see its basically Railsonfire vs. Tddium
What are the factors that we should consider in choosing to use one vs. the other?
A similar question was asked at the link below, but it appears that this was before the add-ons above were created.
Proper continuous integration and continuous deployment with Git and Heroku
Another option is CircleCi, which makes it incredibly easy, though it isn't yet in the Heroku add-on marketplace.
I personally believe speed is the major consideration. The speed at which your team moves is tied to how quickly you can get notifications, and a platform optimized for speed is going to make a major difference.
In addition, on slow platforms, tests may fail randomly (for example, Cucumber might fail if a button doesn't appear in 3 seconds, which may not happen soon enough on a slow platform).
I'm a founder of CircleCi, and we make an incredibly fast CI solution (faster than both services you mentioned). It's really easy to set up (one-click), though it's not in the Heroku marketplace (yet).
One consideration I'd give you to… uh… consider is support. I don't know anything about the Tddium team, but I do know that a couple months ago I tried Rails On Fire was blown away by the support. I asked some crazy questions (I do crazy things) and Florian responded in email and on Twitter right away with both help and suggestions.
Then, when I decided not to use the service because it couldn't support one edge-case feature, he implemented the feature! I hadn't been using it for a couple weeks and he wrote back to me personally to say "Hey, we finally got that feature you thought would be helpful."
I've used Hudson/Jenkins for years and know what you mean about complexity. But I also think that having someone on the other end is pretty key, and the RailsOnFire team, for now at least, do that quite well.
Related
For a mostly static website without a lot of stuff going on in the back end, how many page views can the free version of heroku handle (ruby on rails). Can it handle 100 a month, 1,000, 10,000, etc. When shoudl I consider upgrading it and are there better services? Thanks in advance!
Unfortunately, the only real answer to this question is "It depends". It depends on how many database calls you are making, whether or not those database calls are optimized, whether you have any form of caching in place, etc.
However, I am currently in a similar situation as you and just launched an early stage startup on Heroku. I highly recommend installing New Relic (don't worry, there's a free tier) to keep an eye on site usage/statistics.
Another (free!) addon I installed was Papertrail, which allows me to keep a close eye on the Heroku logs, and trigger alerts if there are too many errors (which could mean it's time to scale-up).
On the other side, you can test your Heroku server by sending load to it using the Apache Bend tool. See this answer for a good explanation.
Lastly, I would take a look at this question, which provides many good references on Heroku performance.
Good luck!
Heroku is free for up to 5 apps. Each app has access to 750 dyno-hours per month. That should be more then enough for a mostly static site.
I get about 4k-5k visitors per month on a Ruby app, but with a lot of caching.
I am looking to start developing a relatively simple web application that will pull data from various sources and normalizing it. A user can also enter the data directly into the site. I anticipate hitting scale, if successful. Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack? Framework or not? Any thoughts, suggestions, or comments would help.
Disregard my vague description of the idea, I'd love to share once I get further along.
Later. I can't remember who said it (might have been SO's Jeff Atwood) but it rings true: your first problem is getting other people to care about your work. Worry about scale when they do.
Definitely go with a well structured framework for your own sanity though. Even if it doesn't end up with thousands of users, you'll want to add features as time goes on. Maintaining an expanding codebase without good structure quickly becomes fairly horrible (been there, done that, lost the client).
btw, if you're tempted to write your own framework, be aware that it is a lot of work. My company has an in-house one we're quite proud of, but it's taken 3-4 years to mature.
Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack?
A LAMP stack is scalable. Apache provides many, many alternatives.
Framework or not?
Always use the highest-powered framework you can find. Write as little code as possible. Get something in front of people as soon as you can.
Focus on what's important: Get something to work.
If you don't have something that works, scalability doesn't matter, does it?
Then read up on optimization. http://c2.com/cgi/wiki?RulesOfOptimization is very helpful.
Rule 1. Don't.
Rule 2. Don't yet.
Rule 3. Profile before Optimizing.
Until you have a working application, you don't know what -- specific -- thing limits your scalability.
Don't assume. Measure.
That means build something that people actually use. Scale comes later.
Absolutely do it later. Scaling pains is a good problem to have, it means people like your project enough to stress the hardware it's running on.
The last company I worked at started fairly small with PHP and the very very first versions of CakePHP that came out (when it was still in beta). Some of the code was dirty, the admin tool was a mess (code-wise), and sure it could have been done better from the start. But do you know what? They got it out the door before their competitors did, and became extremely successful.
When I came on board they were starting to hit the limits of their current potential scalability, and that is when they decided to start looking at CDN's, lighttpd caching techniques, and other ways to clean up the code and make things run smoother when under heavy load. I don't work for them anymore but it was a good experience in growing an architecture beyond what it was originally scoped at.
I can tell you right now if they had tried to do the scalability and optimizations before selling content and getting a website live - they would never have grown to the size they are now. The company is www.beatport.com if you're interested in who I'm talking about (To re-iterate, I'm not trying to advertise them as I am no longer affiliated with them, but it stands as a good case study and it's easier for people to understand what I'm talking about when they see their website).
Personally, after working with Ruby and Rails (and understanding the separation!) for a couple of years, and having experience with PHP at Beatport - I can confidently say that I never want to work with PHP code again =p
Funny to ask "scale now or later?" and label it "ruby on rails".
Actually, Ruby on Rails was created by David Heinemeier Hansson, who has a whole chapter in his book labeled "Scale later" :))
http://gettingreal.37signals.com/ch04_Scale_Later.php
I agree with the earlier respondents -- make it useful, make it work and get people motivated to use it first. I also agree that you should pick off-the shelf components (of which there are many) rather than roll your own, as much as possible. At the same time, make sure that you choose components for your infrastructure that you know to be scalable so that you can go there when you need to, without having to re-write major chunks of your application.
As the Product Manager for Berkeley DB, I've seen countess cases of developers who decided "Oh, we'll just write that to a flat file" or "I can write my own simple B-tree function" or "Database XYZ is 'good enough', I don't have to worry about concurrency or scalability until later". The problem with that approach is that a) you're re-inventing the wheel (and forgoing what others have learned the hard way already) and b) you're ignoring the fact that you'll have to deal with scalability at some point and going with a 'good enough' solution.
Good luck in your implementation.
I know this is not a really programmic question, but which one should I deploy my app too?
Basically, I will have a straight forward Rails app with a a decent database usage. Heroku is obviously a great platform and has a lot of gimmicks. Duostack however seems to getting bigger and bigger while still in beta, and I really like their autoscaling feature, since I wouldn't have to monitor my site like 24/7 to be as cost efficient as possible.
Secretly, I just hope that Amazon will extend Elastic to Rails, but that would probably take a while
Well you have to get an invite to use Duostack, I don't know how hard that is. Plus, if you're looking to do a production app, they're still in Beta so there's no 100% guarantee things will be stable, or that there won't be API changes.
ALso, is duostack going to offer a free usage tier?
If you're comfortable with the answers to all those questions, then just go for whichever one you like better.
One nice thing about Heroku is it is well-established enough to have a lot of third party integration, and that can make development just blissful if it includes the integrations you need :)
Probably not a wrong choice between the two, though. Request a beta invite and if you get in, try both. Since all you have to do is "git push" to deploy to both, it ought to be pretty easy to do a direct side-by-side comparison of the workflow.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm trying to decide between Heroku and Engineyard.
Heroku seems so much better but they charge for everything and their prices are crazy!
Why one should use Heroku over EY or vice versa?
Heroku makes setup and launching of an app super-simple. You will be dependent to some degree on versions that Heroku supports (for instance, I heard today of a bundler versioning issue).
One thing to take into account with any "managed full-stack" solution like Heroku or EY is cost. You don't have to hire an ops person or have ops expertise, but you're still paying. Storage is where things get really expensive. Crank up your DB to a more than a few GB and watch the price go up.
We have in-house ops (was me doing it while coding, now a dedicated person) and run on Joyent. A big cost savings was having a few master-slave DBs and sharing them among a few dozen applications. We essentially have 100 Facebook apps running on Joyent at the same cost as 10 apps on Heroku. But this doesn't take into account the ops salary/time.
Everyone's needs are different, but the great thing is that its easy to experiment with these cloud deployment tools in quick fashion, and you will find that they each have their own strengths that you can leverage as you need.
What is most valuable to me, and my smaller clients, is to be able to experiment and get end-user feedback quickly. I have startup clients that want to be able to push out new ideas and test them quickly, deploy different combinations of ideas to different markets, get customer feedback, and keep moving forward. Launch a facebook app, a test server for an API integration client, a lightweight 'freemium' version of a product, etc. As traffic picks up, we make changes to scale up, and the increase in cost is never out of bounds (eg. our hosting costs are still well under the increase in value/revenue/marketing juice, etc).
EngineYard lets you play around with 500hrs for free, and you can easily turn it off when you are not using it, to stretch the 500hrs out. You can deploy your app quickly, deploy a CI server (that updates the app on every successful build), create a backup of your app or 'staging' server and see how it goes.
Amazon will give you 750hrs per month for free, for a year, if you are a new AWS customer. You can use this for a super fast CI server, hard-core image processing, batch reporting, whatever.
Personally I happen to use Heroku the most, as it just seems to work the best for my needs. I can put together a new application with full monitoring, backup, analytics, email, etc really fast, and feel confident in how to manage my setup (and confident that I can bring another person on board, and their learning curve will be pretty easy). As a freelancer, my use of Heroku has brought my setup time down to almost nothing, so I'm able to focus my time on understanding the business, and developing a great product. I'm not saying that can't be done on other platforms, I'm just saying heroku is working great for me in that way.
I do have one app that processes Voip data over UDP, so I'll need to figure out if I prefer amazon or engineyard for that (heroku won't let you open a UDP port, as far as I know).
I recently put together a presentation on these tools, and how I use them. (it was for newer developers, so it may be too basic for this audience, but there is a list of pros/cons that others may find useful)
Also, I think this conversation does belong here, and not necessarily on a webmasters forum, because the choice of hosting platform will influence your development capabilities and architecture, and the people making the decision are developers, not 'webmasters' or systems people.
I'd vote to use EngineYard over Heroku. Although you can probably deploy a large scale application on Heroku, there's a lot of lock-in you'll have to endure and the pricing can become crippling at higher levels of use.
EngineYard does provide application-level support, too, which is a fair bit better than what Heroku does.
If you're making a quick hobby application or simple demo site, Heroku is great for launching small, simple instances. If you're building a real application where it will need to scale, use EngineYard.
We have been running our platform on Heroku for about 9 months, and I am very satisfied.
I think the biggest complaint that most people have is that it gets "expensive" when your site gets large or high traffic. Personally, I think it is much more effective to focus on growing your business or improving your value proposition than maintaining servers or figuring how to get Rails working. (It is no easy task unless you want to spend a lot of time figuring it out). I would much rather pay Heroku to manage the servers for me than hire someone.
Here's what's great about Heroku:
Pretty easy to use. I didn't know anything about Rails when I got started, and Heroku was simple to get working.
Good documentation for most things.
OK tech support.
Extremely cost effective when you are small.
Heroku is pretty smart, and I am sure they are going to read this, so here's what can be improved:
Tech support: Typically you ask a question and they respond, and that begs a new obvious question. The tech support person should answer the next question I am going to ask. For example, I might ask how to do something, and then they tell me a certain way of doing it. Now I need information about it. Supply all the information in the first response, so I don't have to ask, "How do I use it?"
Documentation: Everyone has the same questions. The documentation could be greatly improved by adding all the questions and answers that I have asked, let alone the tens of thousands of other customers.
Logs: The free logging options are useless, and $100/month for real logs is silly. Our solution has been http://papertrailapp.com which has been outstanding. Use it.
I might as well throw my opinion in here since I have "tried" to use EngineYard and "successfully" use Heroku. While I think both are potentially good choices, I found deploying to Heroku much easier. The ala-carte pricing for Heroku add-ons may add expense, but it also gives you the opportunity to add functionality immediately to your app. The largest expense for our app is the actual web dynos, followed by the database. Heroku has a great selection of add-ons, many of which are free or low cost.
EngineYard also seems like a great company but I think they "hold your hand" a little less than Heroku. For my company, the benefits of Heroku outweighed the cost issue. The read-only filesystem which is a platform feature of Heroku also forces you to learn some new tricks.
I now have several apps (small to medium) on Heroku and happily have my assets served up from s3.
In the end, I would encourage you to try them both. EngineYard offers a 500 hour trial (though that is computing hours, not necessarily real-time hours) and Heroku let's you get started right away for pretty much free.
PS: When selecting add-ons consider your choice carefully, just like when you choose gems for your project. I have experienced an add-on that I was using, simply flaming out and had to scramble to replace that functionality. What was it? Progstr-Filer, which I was using for file uploads. That was a lesson learned.
It depends of the condition. On some case, it's highly expensive
Here we can get a 24 GB o RAM dedicated server for 99 euros.
I can have it set up an running my rail app in less than half an hour, with a mongodb database, as many runner that I want, etc...
Additionally, I can add "small" other project (the ones that costs between 15$ and 35$ monthly at Heroku)
If your business require huge amount of data and processing power, my advice is to use a dedicated hosting and spend the time in managing and monitoring your app.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.