Ouch - this just landed in my inbox (and I'm sure others):
"At JetBrains, we feel we provide a great value to the marketplace. In spite of the industry trends, we have held the IntelliJ IDEA price unchanged for the past 5 years. To maintain the same level of quality in our product and services, we now find it necessary to increase the IntelliJ IDEA regular price from $ 499 to $ 599.
The new IntelliJ IDEA license price of $ 599 will be effective from February, 15th, 2008. Any IntelliJ IDEA license purchases made before February, 15th, 2008 will be honored at the current price of $ 499."
I'm already seeing resistence at work to upgrade/buy new licenses for new devs - I can see this price change being a final nail in my fight against our new pro-eclipse manager.. :(
What do people think the general response will be?
-- "The L in LAMP stands for Linux, not Looney" - Jonathan Schwartz, Sun Microsystems, Inc.
It's a shame but I can understand. I'm a huge fan of Idea and have been since version 2.0. Each release gets better and better, the most recent big addition for me is the Groovy support they added in 7.
This is one of those tools that I would spend my own hard earned money to use and we have a ton of Open Source gear in our stack. IDEs aren't one of them.
Todd
________________________________
From: javaposse@googlegroups.com [mailto:javaposse@googlegroups.com] On Behalf Of Mark Derricutt Sent: Thursday, February 07, 2008 10:15 AM To: javaposse@googlegroups.com Subject: [The Java Posse] Jetbrains increase cost of IDEA by US$100
Ouch - this just landed in my inbox (and I'm sure others):
"At JetBrains, we feel we provide a great value to the marketplace. In spite of the industry trends, we have held the IntelliJ IDEA price unchanged for the past 5 years. To maintain the same level of quality in our product and services, we now find it necessary to increase the IntelliJ IDEA regular price from $ 499 to $ 599.
The new IntelliJ IDEA license price of $ 599 will be effective from February, 15th, 2008. Any IntelliJ IDEA license purchases made before February, 15th, 2008 will be honored at the current price of $ 499."
I'm already seeing resistence at work to upgrade/buy new licenses for new devs - I can see this price change being a final nail in my fight against our new pro-eclipse manager.. :(
What do people think the general response will be?
-- "The L in LAMP stands for Linux, not Looney" - Jonathan Schwartz, Sun Microsystems, Inc.
Mark Derricutt wrote: > Ouch - this just landed in my inbox (and I'm sure others):
> "At JetBrains, we feel we provide a great value to the marketplace. In > spite of the industry trends, we have held the IntelliJ IDEA price > unchanged for the past 5 years. To maintain the same level of quality > in our product and services, we now find it necessary to increase the > IntelliJ IDEA regular price from $ 499 to $ 599.
> The new IntelliJ IDEA license price of $ 599 will be effective from > February, 15th, 2008. Any IntelliJ IDEA license purchases made before > February, 15th, 2008 will be honored at the current price of $ 499."
> I'm already seeing resistence at work to upgrade/buy new licenses for > new devs - I can see this price change being a final nail in my fight > against our new pro-eclipse manager.. :(
> What do people think the general response will be?
Well, Eclipse is now $600 cheaper. ;-)
I really sympathize with JetBrains. Here they are making a great product trying to make a living from it and they have to complete with 3 free products, 2 of which were essentially losers in the market place prior to being dumped into the open source community. It is funny how pay for losers have now become "free" winners. Mostly this is because companies have mistaken free to mean we don't have to pay. And who can blame them. Why should they pay these licenses if there is no compelling business case to do so. In fact maybe that is your answer, make a compelling business case or anti up for your own license. $600 isn't a lot of money for a tool that you use so intimately in your day to day work.
IntelliJ is by far my favorite. I have already spent half the morning
arguing with an eclipse build. Software professionals must already
have a fairly low cost in regards to non-wage outlays and tools.
While I have an OSS license for IntelliJ myself and would find it
difficult to justify the cost, I cant see why an employer should not
invest such a small arount relative to all the other expenses. If you
are looking to cut a cost, choose something that realy is less
important in the bigger scheme of things (drop a salesman or don't buy
that extra 16 processor server you won't even use anyway?? :)
We recently chose an IDE as a standard tool across a very large
organization. The main problem there was the large and varying number
of seats. I still voted IntelliJ but it wasn't to be. I wont tell
you what was chosen. I want to maintain some facade of respect on
this forum.
On Feb 7, 12:34 pm, Kirk <kirk.pepperd...@gmail.com> wrote:
> Mark Derricutt wrote:
> > Ouch - this just landed in my inbox (and I'm sure others):
> > "At JetBrains, we feel we provide a great value to the marketplace. In
> > spite of the industry trends, we have held the IntelliJ IDEA price
> > unchanged for the past 5 years. To maintain the same level of quality
> > in our product and services, we now find it necessary to increase the
> > IntelliJ IDEA regular price from $ 499 to $ 599.
> > The new IntelliJ IDEA license price of $ 599 will be effective from
> > February, 15th, 2008. Any IntelliJ IDEA license purchases made before
> > February, 15th, 2008 will be honored at the current price of $ 499."
> > I'm already seeing resistence at work to upgrade/buy new licenses for
> > new devs - I can see this price change being a final nail in my fight
> > against our new pro-eclipse manager.. :(
> > What do people think the general response will be?
> Well, Eclipse is now $600 cheaper. ;-)
> I really sympathize with JetBrains. Here they are making a great product
> trying to make a living from it and they have to complete with 3 free
> products, 2 of which were essentially losers in the market place prior
> to being dumped into the open source community. It is funny how pay for
> losers have now become "free" winners. Mostly this is because companies
> have mistaken free to mean we don't have to pay. And who can blame them.
> Why should they pay these licenses if there is no compelling business
> case to do so. In fact maybe that is your answer, make a compelling
> business case or anti up for your own license. $600 isn't a lot of money
> for a tool that you use so intimately in your day to day work.
--- Christian Catchpole <christ...@catchpole.net> wrote:
> We recently chose an IDE as a standard tool across a very large > organization. The main problem there was the large and varying number > of seats. I still voted IntelliJ but it wasn't to be. I wont tell > you what was chosen. I want to maintain some facade of respect on > this forum.
This kind of scenario is why I wish there were better IDE standards. Does anybody really care what fonts you set to edit text? Does anybody really care what keyboard shortcuts you use? No. But do people care that each developer builds their test environment the same way? Yes. Do they care that each developer has access to the same features pertinent to the project, like remote debugging for instance? Absolutely. In many ways we already have such standards: using an Ant or Maven project file instead of a proprietary IDE project format. But we could benefit from more such standards-driven flexibility (AST editing).
> --- Christian Catchpole <christ...@catchpole.net> wrote:
> > We recently chose an IDE as a standard tool across a very large > > organization. The main problem there was the large and varying number > > of seats. I still voted IntelliJ but it wasn't to be. I wont tell > > you what was chosen. I want to maintain some facade of respect on > > this forum.
> This kind of scenario is why I wish there were better IDE standards. Does > anybody really care what fonts you set to edit text? Does anybody really > care > what keyboard shortcuts you use? No. But do people care that each > developer > builds their test environment the same way? Yes. Do they care that each > developer has access to the same features pertinent to the project, like > remote > debugging for instance? Absolutely. In many ways we already have such > standards: using an Ant or Maven project file instead of a proprietary IDE > project format. But we could benefit from more such standards-driven > flexibility (AST editing).
I have been working in environments where people didn't care about which IDE you are using. The official build is done by Ant on the build server in any case, so why should they? Of course there should be at least one officially supported one people can default to, but if someone else feels more comfortable to deviate that's fine.
OTOH it duplicates some configuration efforts (but I think that should be negligible) and sometimes you can get extra boni from committing fully to one IDE. For example I am working on one OSS project where we decided to use a few more advanced features of Eclipse, including running the formatting and other code fixup on each save. If you want to configure multiple code formatters you will find that there is much more work. And running the formatter out-of-band means getting the formatting as separate commits or even mixed with unrelated change. But of course we don't mind anyone using a different IDE, but I suspect the formatter problems will grow with the size of their commits. It's really a tradeoff and since all core devs where using Eclipse anyway we went down that route (and so far I like it -- it's good to be able to just code messily formatted, knowing Eclipse will give you a more-or-less canonical form once you save).
> On Feb 8, 2008 6:06 AM, Alexey Zinger <inline_f...@yahoo.com> wrote:
> > --- Christian Catchpole <christ...@catchpole.net> wrote:
> > > We recently chose an IDE as a standard tool across a very large > > > organization. The main problem there was the large and varying number > > > of seats. I still voted IntelliJ but it wasn't to be. I wont tell > > > you what was chosen. I want to maintain some facade of respect on > > > this forum.
> > This kind of scenario is why I wish there were better IDE standards. Does > > anybody really care what fonts you set to edit text? Does anybody really > > care > > what keyboard shortcuts you use? No. But do people care that each > > developer > > builds their test environment the same way? Yes. Do they care that each > > developer has access to the same features pertinent to the project, like > > remote > > debugging for instance? Absolutely. In many ways we already have such > > standards: using an Ant or Maven project file instead of a proprietary IDE > > project format. But we could benefit from more such standards-driven > > flexibility (AST editing).
> I have been working in environments where people didn't care about which IDE > you are using. The official build is done by Ant on the build server in any > case, so why should they? Of course there should be at least one officially > supported one people can default to, but if someone else feels more > comfortable to deviate that's fine.
> OTOH it duplicates some configuration efforts (but I think that should be > negligible) and sometimes you can get extra boni from committing fully to > one IDE. For example I am working on one OSS project where we decided to use > a few more advanced features of Eclipse, including running the formatting > and other code fixup on each save. If you want to configure multiple code > formatters you will find that there is much more work. And running the > formatter out-of-band means getting the formatting as separate commits or > even mixed with unrelated change. But of course we don't mind anyone using a > different IDE, but I suspect the formatter problems will grow with the size > of their commits. It's really a tradeoff and since all core devs where using > Eclipse anyway we went down that route (and so far I like it -- it's good to > be able to just code messily formatted, knowing Eclipse will give you a > more-or-less canonical form once you save).
> Peter
I'm a big believer in AST editing. Once we have that, everyone can view the code however they want without affecting anyone else. Where the tabs and newlines code in C-like syntax, after all, is just a matter of style.
> --- Peter Becker <peter.becker...@gmail.com> wrote:
> > On Feb 8, 2008 6:06 AM, Alexey Zinger <inline_f...@yahoo.com> wrote:
> > > --- Christian Catchpole <christ...@catchpole.net> wrote:
> > > > We recently chose an IDE as a standard tool across a very large > > > > organization. The main problem there was the large and varying > number > > > > of seats. I still voted IntelliJ but it wasn't to be. I wont tell > > > > you what was chosen. I want to maintain some facade of respect on > > > > this forum.
> > > This kind of scenario is why I wish there were better IDE standards. > Does > > > anybody really care what fonts you set to edit text? Does anybody > really > > > care > > > what keyboard shortcuts you use? No. But do people care that each > > > developer > > > builds their test environment the same way? Yes. Do they care that > each > > > developer has access to the same features pertinent to the project, > like > > > remote > > > debugging for instance? Absolutely. In many ways we already have > such > > > standards: using an Ant or Maven project file instead of a proprietary > IDE > > > project format. But we could benefit from more such standards-driven > > > flexibility (AST editing).
> > I have been working in environments where people didn't care about which > IDE > > you are using. The official build is done by Ant on the build server in > any > > case, so why should they? Of course there should be at least one > officially > > supported one people can default to, but if someone else feels more > > comfortable to deviate that's fine.
> > OTOH it duplicates some configuration efforts (but I think that should > be > > negligible) and sometimes you can get extra boni from committing fully > to > > one IDE. For example I am working on one OSS project where we decided to > use > > a few more advanced features of Eclipse, including running the > formatting > > and other code fixup on each save. If you want to configure multiple > code > > formatters you will find that there is much more work. And running the > > formatter out-of-band means getting the formatting as separate commits > or > > even mixed with unrelated change. But of course we don't mind anyone > using a > > different IDE, but I suspect the formatter problems will grow with the > size > > of their commits. It's really a tradeoff and since all core devs where > using > > Eclipse anyway we went down that route (and so far I like it -- it's > good to > > be able to just code messily formatted, knowing Eclipse will give you a > > more-or-less canonical form once you save).
> > Peter
> I'm a big believer in AST editing. Once we have that, everyone can view > the > code however they want without affecting anyone else. Where the tabs and > newlines code in C-like syntax, after all, is just a matter of style.
-- _____________________________________ / \ /lift/ committer (www.liftweb.net) SGS member (Scala Group Sweden) SEJUG member (Swedish Java User Group) \_____________________________________/
I agree, but since I don't have it I find the canonicalization by the Eclipse formatter the next best choice.
It doesn't do the best job, but it is good enough and the fact that it comes with the save action (and thus very early, definitely before the commit) makes me stop thinking about formatting most of the time.
I'm not trying to promote Eclipse here, though (in fact I think its quality seems to go downhill lately), but I think that feature is very cool to have. If your favorite IDE has it you should try :-)
BTW: I don't think of IDEA as an option for an OSS project since it is not accessible for people curious about it. I know you can get free licences, but that is a process too involved. Currently my instructions for people wanting to try our OSS stuff look like this:
- install a JDK and Eclipse - install Subclipse - check out this URL - go for it
The result of that might not be optimal, but it is nice and easy. If you have to configure libraries, formatted and all the rest it isn't that easy anymore. If you have to apply for an IDE licence it gets too complicated -- assuming you can get one based on the "I'd like to check out this project" notion.
Peter
On Feb 8, 2008 8:43 AM, Alexey Zinger <inline_f...@yahoo.com> wrote:
> --- Peter Becker <peter.becker...@gmail.com> wrote:
> > On Feb 8, 2008 6:06 AM, Alexey Zinger <inline_f...@yahoo.com> wrote:
> > > --- Christian Catchpole <christ...@catchpole.net> wrote:
> > > > We recently chose an IDE as a standard tool across a very large > > > > organization. The main problem there was the large and varying > number > > > > of seats. I still voted IntelliJ but it wasn't to be. I wont tell > > > > you what was chosen. I want to maintain some facade of respect on > > > > this forum.
> > > This kind of scenario is why I wish there were better IDE standards. > Does > > > anybody really care what fonts you set to edit text? Does anybody > really > > > care > > > what keyboard shortcuts you use? No. But do people care that each > > > developer > > > builds their test environment the same way? Yes. Do they care that > each > > > developer has access to the same features pertinent to the project, > like > > > remote > > > debugging for instance? Absolutely. In many ways we already have > such > > > standards: using an Ant or Maven project file instead of a proprietary > IDE > > > project format. But we could benefit from more such standards-driven > > > flexibility (AST editing).
> > I have been working in environments where people didn't care about which > IDE > > you are using. The official build is done by Ant on the build server in > any > > case, so why should they? Of course there should be at least one > officially > > supported one people can default to, but if someone else feels more > > comfortable to deviate that's fine.
> > OTOH it duplicates some configuration efforts (but I think that should > be > > negligible) and sometimes you can get extra boni from committing fully > to > > one IDE. For example I am working on one OSS project where we decided to > use > > a few more advanced features of Eclipse, including running the > formatting > > and other code fixup on each save. If you want to configure multiple > code > > formatters you will find that there is much more work. And running the > > formatter out-of-band means getting the formatting as separate commits > or > > even mixed with unrelated change. But of course we don't mind anyone > using a > > different IDE, but I suspect the formatter problems will grow with the > size > > of their commits. It's really a tradeoff and since all core devs where > using > > Eclipse anyway we went down that route (and so far I like it -- it's > good to > > be able to just code messily formatted, knowing Eclipse will give you a > > more-or-less canonical form once you save).
> > Peter
> I'm a big believer in AST editing. Once we have that, everyone can view > the > code however they want without affecting anyone else. Where the tabs and > newlines code in C-like syntax, after all, is just a matter of style.
Yeah, I don't think builds should be tied to an IDE. If anything, the
diversity promotes a clean and stable build. So much time is spent
configuring and maintaining IDE environments. And I have yet to see
an IDE/build/source control configuration that is used in the way it
was intended.
I have suspicion for any employer that won't let me use my choice of
IDE and do it on my Mac. Perhaps they don't take software development
seriously. :)
> So much time is spent configuring and maintaining IDE environments.
By that I meant, I often walk onto a project, spend half a day setting
up the build, asking around for all the undocumented steps and still
have no confidence its building as expected. I should be able to...
1> check out
2> set custom backend hosts etc
3> build
> I'm a big believer in AST editing. Once we have that, everyone can > view the > code however they want without affecting anyone else. Where the > tabs and > newlines code in C-like syntax, after all, is just a matter of style.
Wait?! So are you saying that here in the 21st century we *shouldn't* be saving our valuable code in a 40 year old text file format? Surely you jest, good sir! This is an insult to the queen. I challenge you to a du-el!
> > I'm a big believer in AST editing. Once we have that, everyone can > > view the > > code however they want without affecting anyone else. Where the > > tabs and > > newlines code in C-like syntax, after all, is just a matter of style.
> Wait?! So are you saying that here in the 21st century we *shouldn't* > be saving our valuable code in a 40 year old text file format? > Surely you jest, good sir! This is an insult to the queen. I challenge > you to a du-el!
> :)
Actually, my good sir, I'm not saying that at all. We can continue to store our code in a 40 year old text format, but that doesn't mean we should view and edit it as such, though it should continue to be an option. Here's my crackpot vision:
We don't need to modify IDE's (but we can), we don't need to modify code repositories, build tools JVM. The only thing we need to modify is the version control _client_ that will include some intelligence about AST, hopefully in an extensible fashion so that new syntaxes could be piggybacked onto existing software. What these modules would do is attempt to control the format of known syntaxes on the client side and on the server side for updates/checkouts and, very importantly, diffs. And all of a sudden, all existing development tools continue to work with no mods required, teams can optionally standardize what kind of formatting goes into the repository, and individual developers can optionally configure how said code is presented to them. Whether they edit AST using heads-up displays and brain wave scanners or whether they continue to type :wq will make no difference to anyone else.
I was pleasently supprised when I first discovered that JAR files were
just ZIP files. Not commenting on the ZIP file structure itself, it
just seemed far too easy and practicle to be true.
ps. Im visiting head office in Florida (I live in Brisbane
Australia). Its nice to be in the same time zone as most of the
posters here.. although i know at least 2 fellow Brisvegas-ites, Peter
B. and Michael N.
On Feb 8, 11:37 am, Joshua Marinacci <jos...@gmail.com> wrote:
> > I'm a big believer in AST editing. Once we have that, everyone can
> > view the
> > code however they want without affecting anyone else. Where the
> > tabs and
> > newlines code in C-like syntax, after all, is just a matter of style.
> Wait?! So are you saying that here in the 21st century we *shouldn't*
> be saving our valuable code in a 40 year old text file format?
> Surely you jest, good sir! This is an insult to the queen. I challenge
> you to a du-el!
On Feb 9, 2008 2:37 AM, Joshua Marinacci <jos...@gmail.com> wrote:
> > I'm a big believer in AST editing. Once we have that, everyone can > > view the > > code however they want without affecting anyone else. Where the > > tabs and > > newlines code in C-like syntax, after all, is just a matter of style.
> Wait?! So are you saying that here in the 21st century we *shouldn't* > be saving our valuable code in a 40 year old text file format? > Surely you jest, good sir! This is an insult to the queen. I challenge > you to a du-el!
I use UTF-8 instead of ASCII nowadays. Not that it makes any difference for the source files but it sounds more modern.
With maven, depending on how complex the environment, you can get this
or something close to it. Our team, has mostly eclipse users (many of
which want to be IntelliJ users), and some IntelliJ users (that
decided shelling out for the IDE was worth it). The process boils down
to (if starting from scratch).
1> check out
2> mvn idea:idea
or
mvn eclipse:eclipse
3> IntelliJ - open the project file
Eclipse - open a workspace and import the projects
4> Build
The maven build takes maintenance, but you can get push button
releases and continuous integration out of the deal.
By the way, Jetbrains has a personal license in the line-up that
allows an individual to purchase it for $249 (US) that can be used for
work, home, wherever. http://www.jetbrains.com/idea/buy/index.html
Matt
On Feb 8, 6:04 am, Christian Catchpole <christ...@catchpole.net>
wrote:
> > So much time is spent configuring and maintaining IDE environments.
> By that I meant, I often walk onto a project, spend half a day setting
> up the build, asking around for all the undocumented steps and still
> have no confidence its building as expected. I should be able to...
> 1> check out
> 2> set custom backend hosts etc
> 3> build
The personal license makes a lot of sense. Now your company might
want to buy flexible licenses in case you leave. But even if they
wont let you expense it, it could be a personal tax deduction. *
* not tax advise - check with your local overlords.
On Feb 9, 12:54 am, mattz <zimmer.m...@gmail.com> wrote:
> With maven, depending on how complex the environment, you can get this
> or something close to it. Our team, has mostly eclipse users (many of
> which want to be IntelliJ users), and some IntelliJ users (that
> decided shelling out for the IDE was worth it). The process boils down
> to (if starting from scratch).
> 1> check out
> 2> mvn idea:idea
> or
> mvn eclipse:eclipse
> 3> IntelliJ - open the project file
> Eclipse - open a workspace and import the projects
> 4> Build
> The maven build takes maintenance, but you can get push button
> releases and continuous integration out of the deal.
> By the way, Jetbrains has a personal license in the line-up that
> allows an individual to purchase it for $249 (US) that can be used for
> work, home, wherever.http://www.jetbrains.com/idea/buy/index.html
> Matt
> On Feb 8, 6:04 am, Christian Catchpole <christ...@catchpole.net>
> wrote:
> > > So much time is spent configuring and maintaining IDE environments.
> > By that I meant, I often walk onto a project, spend half a day setting
> > up the build, asking around for all the undocumented steps and still
> > have no confidence its building as expected. I should be able to...
> > 1> check out
> > 2> set custom backend hosts etc
> > 3> build
