I am looking at Quartz.Net and it seems to be almost a year ago.
I am wondering if they stopped development on it or it the next versions is just taking a while to do?
I am asking this because I really don't like to invest time in something that is at the end of its life or not being developed on anymore because I just know in the future I going to have to upgrade to something different so might as well just start with something else.
Of course whatever I choose might not be developed on in the future either but I like to see new versions to be a few months within the time I start to use that product.
If it is dead anyone have any other alternatives that are being still worked on and have the same features as Quartz?
Quartz.NET development hasn't stopped at all, it just moved to github. If you check the source repository at sourceforge, the last commit was 4 months ago and it clearly says "Source moved to GitHub, removing trunk as it's misleading at the moment".
The github repository has currently 28 watchers and 8 forks, and active contributors (i.e. it's not a one-man show) so the project is definitely not going to die any time soon.
By the way, the latest release was 1.0.3 (August 2010), at the time of this writing this is much less than a year ago.
Quartz.net is actually very active. I've written to #lahma a couple of time for bugs and he fixed it in a very short time.
A couple of months ago I had tried the 2.0 and it was a little bit buggy.
I know there's a new API. You might give it a go.
Related
I started a new job a few months ago where the whole business relies on Delphi 7-built applications and interfaces to external systems and partners. A lot of 3rd party components are used, such as the whole DevExpress library, Indy, TMS components, Turbopower, SDAC, and many more, for a total of about 20.
This is the state of things and none of it can be changed (the company has over 1000 employees).
Now, compiling their main application takes around 7 minutes and has over 2M lines of code. All the workstations run on VMWare, which might account for part of the compile time. This compile time is the same, even when server/network load is minimal at night.
Changing a single line of code will cause a simple compile to take 4 to 5 minutes, even if nothing else changed. I cannot use code completion or code parameters is impractical as it incurs a delay about as long as a compile.
Is there anything I could do to improve compile time? I ran some ideas by the manager, and DLLs or any type of external dependencies are out of the question. Upgrading to a newer version of Delphi is out of the question as they estimated that cost to over half a million dollars, and they plan to do that at a much later date.
Someone mentioned putting all 3rd party files in their own separate packages since they never change, but I'm not experienced with packages enough to know if that would help compile times.
I did some searching over the last few weeks, but I did not find any ideas that would apply to my situation.
Thanks in advance for any tips!
PS: I need to add that I tried DelphiSpeedUp and other tools with no help in compile times.
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.
We are currently running rails 2.1.
My main motivation for the upgrade is the fear that gems/plugins will get rarer/unavailable/unsupported day by day for our version (,and the excitement of the latest technology).
I understand there are many-many improvements that come with rails3, but probably what my manager would want to listen is the advantages that he'd get, in terms of the business.
Ours is a Saas application, load on the app is not very high, but the demand for reliability is more.
Edit :
Looks like my inclination towards the upgrade needs rethinking, so answers to "should I upgrade" are welcome.
my original question also needs answers - how to describe the business advantages of an upgrade from rails2.1 -> rails3.
The app is under active development/enhancements.
The longer you go without upgrading, the harder it will be when the time comes. Sooner or later, any actively maintained project is going to have to move up to the more recent versions, and the more versions you have to skip along the way, the harder and more risky it will be. If you upgrade regularly, it becomes a fairly simple maintenance task.
I'm afraid that going from 2.1 -> 3.0 is going to be a fairly rough one unless your app is pretty simple. You might try going from 2.1 -> 2.3.9 as a first step. However, doing it now, instead of when it's 2.1 -> 3.1 will save you heartache. Right now, everyone is focused on helping people upgrade. A year from now, there will be fewer fresh resources available and fewer people going out of their way to help people upgrade.
If your application is under development and is likely to have more and more features over the months to come then you should migrate to the newer and actively supported version.
If your application only needs bug fixes occasionally then you should stick to the current version.
Upgrade!
I'd say that you should definitely upgrade, for the reasons you stated, but don't rush it. If you have a well defined test suite everything should be ok.
Most of core Rails 2.x code works with Rails 3, you can just read the deprecation warnings and fix things one by one. You can also use the official Rails Upgrade plugin to automate the bulk of the editing.
As for the gems and plugins you use, you can check their compatibility at railsplugins.org and decide if it's worth the trouble if any.
And the elevator pitch for the boss: You said the app is under development, so upgrading later when you absolutely have to means that you have to first deal with all the issues arising under 2.x and then deal with the upgrade issues plus 3.0 issues of a much bigger app. Upgrading now saves time by saving you the trouble of having to deal with 2.x issues. And you also avoid some of the upgrade issues since your app is probably much leaner now than the heavyweight it will be when you decide to upgrade later.
Since reliability is high on priority, you should probably not upgrade unless it's absolutely required. Some unforeseen issue is bound to come up.
To address the excitement of the latest technology, you can always try out new plugins and Rails 3 offline.
Businesses should not be sandboxes of developers. Nor should development be Resume Driven.
But that's just my opinion. :)
There are several reasons to upgrade, all of which are under the assumption that the app is and will continue to be under active development.
Integration with 3rd party software- for example, rails 1 did not have ActiveSupport. An app remaining on rails1 all through say rails 2 might want to integrate with a 3rd party API that primarily supports restful json. At that point, the sensibile path is to upgrade, but since you delayed it so long your risk of having lots of issues in the upgrade will be significantly greater than if you upgraded early.
Using plugins that will help with new features - if you want to add a new feature and someone has scratched your itch already, then if you are stuck on an older version of rails you will have to write that code yourself. The more code you have to write yourself, the greater the likelyhood of bugs and the more maintaince the code will likely require, depending on the function.
Fixing bugs in older verisons of the plugins/gems - if you encounter a bug in rails, or a plugin, or a gem, or some sort of other integration issue, it might be fixed in a later version, but what that depends on a newer version of rails. This will make your path to fixing said bug or implementing said enhancement greater the longer you wait to upgrade.
If you've purchased the Software Assurance, can you please share your experience? Was it worthwhile?
I vaguely remember reading some negative comments about SA maybe 1 or 2 years ago.
If you normally upgrade each time a new version of Delphi is released, SA is great. It's slightly cheaper than the upgrade pricing, you get the new software right away (no wait for purchasing/ordering), and you get a couple of support incidents thrown in. It also makes it much easier for those of us who have to go through an annual budget battle; you know ahead of time what you'll need to budget per developer for the next year for Delphi updates, instead of having to wait until the version is actually released and then fight for the money.
We've had about the same track record as mj2008, starting with D2007. We bought SA for RAD Studio and not just Delphi, so we also got Prism when it was introduced into RAD Studion 2009 and updated with RAD Studio 2010. (And of course, C++ Builder is thrown in as well.)
I bought SA for D2007, renewed twice, and have had D2009 and D2010 for my troubles.
I think it makes it worth it for me, as I have less to think about and get the software when it comes out.
I agree with Ken. If you intend to upgrade to each new version, SA costs less than upgrading. More so for Enterprise and Architect SKUs than Professional.
SA makes the most sense in the long run. If the goal is to simply get the next release "free", then SA is going to be a gamble.
You can look at Delphi's release history to make an educated guess about future releases and do the math for yourself.
I've used SA in one form or another since Delphi 7, and my experience has been mixed. The worst single screw-up was the release that happened while the development teams were transitioning to CodeGear. In their defense, a lot of people worked hard to sort everything out, but it really was a mess. Since then, it's gotten much better. For the last two releases, I received my SA notice with download instructions within about a day of the RTM announcement. Much better turn around time than the Windows 7 release with my MSDN subscription.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
Now that the Rails 3 beta is here, let's take a little straw poll.
Please tell us briefly what your application does and when you will upgrade it to Rails 3. Or, if you're not planning on upgrading any time soon, tell us what's stopping you.
Honestly? When developers wake up and start work on Rails 3/Ruby 1.9 in their gems and plugins. They know it's been coming for several months now, and most haven't even bothered to upgrade. One in particular that I'd like to point out is authlogic, one of the most used authentication plugins out there. It still doesn't work for Rails 3.
Whoops!
I'm not planning to. I'm sure I'm in a very small minority, but my big application is still running 1.2.6. Each time I consider making the effort to upgrade it seems Rails changes again.
It does what I want it to do, makes good money, and despite feeling more and more left out in the cold I just don't have a sufficiently compelling reason to update it.
All my Rails apps are currently running under Rails 2.3.5 and every app has a LOC of 80% or greater. This has always been a key requirement for every product I create for myself or I manage at work.
Usually, upgrading to a minor/bugfix release is just a matter of a few minutes.
Change GEM version, upgrade requirements, run tests, fix issues and commit.
Rails 3.0 is a major rewrite and the biggest problem is represented by plugin compatibility.
Plugins are not under my direct control. This is the same reason why I had hard time trying to upgrade to Ruby 1.9.1.
However, I'm already playing with Rails 3. I want to learn the most important changes of Rails 3 as soon as possible in order to start moving the existing apps to the right directions. Moreover, as a plugin author, it's important to me to start working with Rails 3 in order to make my plugins compatible.
Yesterday I start with my most simple app. Well, at least this is what I was used to think about it. Anyway, it is the app with the lower number of external dependencies (less than 3 Gems) and it took about 1 hour to upgrade and 3 hour to figure out why Rails was failing to load my routes. It turned out, the Rails Metal component was fighting with the new Rails 3 stack.
There are some minor issues I have to figure out, but I can say I successfully migrated my first app to Rails 3.
I'm planning to migrate all my Rails apps to Rails 3 as soon as possible, once Rails 3 stable will be available. Or at least, as soon as I can figure out whether the dependencies actually work with Rails 3. Fortunately, a project has been started at http://railsplugins.org/ with the intent of listing all compatible/incompatible Rails plugins.
My remote environment is already compatible with Rails 3, I'm using Passenger with Ruby Enterprise Edition (1.8.7). The only blocking issue are plugins.
I guess it would take at least one month before having the major part of my Rails app ready for Rails 3 thought I won't probably start the upgrade until Rails 3 stable is out or I really need the new version for some blocking feature (ex. subdomain-based routing).
I'm not going to upgrade any apps to rails 3.
However, I just decided that all new projects will be rails3 going forward. The lack of plugin support isn't a big issue as I see it as an opportunity to decouple my apps from plugins so that I can swap them in and out as I please later.
I also suspect that the big plugins will upgrade very quickly as they won't want to be left in the dust.
Keep track of plugin status here.
I've been keeping my apps on the edge of 2.3, but since there's a lot of fundamental changes to Rails in 3, I'll probably install the beta, work on converting them over and hope to be ready by the time it's released as stable.
I'm also glad there's a lot of lead time before RailsConf so I can really get familiar with the new features of Rails 3 and won't feel lost/overwhelmed there.
I don't think I'll upgrade any of my applications. It would be a large amount of work compared to what I'd gain from it. Also in some cases the plugins/gems I used in my app are not compatible with Rails 3 so upgrading would be impossible or would require to fork the gems... too time consuming.
If I had to update, I'd probably wait a bit more for all the gems/plugins to be updated to Rails 3. Of course any new application I'll develop will be done using Rails 3.
I'll answer my own question.
I'm not sure how many betas there are going to be for Rails 3, but I'm going to hold off converting my blog application until the next beta or the final release. I think it's going to be quite a time-consuming process because I have a lot of view helpers that build markup, a lot of named scopes and some quite complicated routing.
I want to add page caching first before tackling Rails 3!
After trying out the beta and it not wanting to work with any commands, I have decided to wait until a new beta.
The ticket has already been opened for the issue.
After realising that I probably spend more time in Zend Framework and Doctrine getting code to work (fixing framework bugs, annoying language workarounds, and just plain pain), than actually coding features I decided that it's finally time to give RoR a go. Especially as RoR3 is now out with a bunch of documentation.
5 hours through and it's looking really promising. 1 hour of it was debugging though, some documentation on a plugin was not up to speed, but alas I'm there.
It's interesting, and does seem to be in a better direction. More time to code on features, and less time coding to debug.
So the app I'm converting is my premium CMS that is deployed in over 20 websites now, and powers my own balupton.com - so will be interesting, as the CMS is already a complete featured cms.