Saturday, October 20, 2007
Фанатам IntelliJ IDEA
Taken from here http://www-128.ibm.com/developerworks/java/library/j-java2007.html:
"NetBeans is likely to continue to gain market share at the expense of Eclipse. It's starting from further behind and has more room to grow. (Sun's relentless pushing of NetBeans along with the JDK downloads doesn't hurt either.) By the end of the year, the two IDEs will probably split the market, with each taking half.
Meanwhile, satisfied IntelliJ IDEA users will continue to wonder what all the fuss is about, confident in their belief that it's the best Java IDE available. However, most users won't be able to see beyond its $500 price tag, and thus its market share will continue to hover at around 5%."
Ruby wins the race
Taken from here: http://www-128.ibm.com/developerworks/java/library/j-java2007.html:
"The world would be a boring place if we only spoke one language. While the Java platform is an excellent choice for full-blown application development, it's never really fit the need for small programs or macros. Java 6 recognized this by adding the javax.script package for interoperating with scripting languages like BeanShell, Python, Perl, Ruby, ECMAScript, and Groovy as well as an invokedynamic virtual machine instruction to allow direct compilation of dynamically typed languages to the Java VM.
For 2007, my money is on Ruby, although it's not actually my personal favorite. Python code seems to me a lot cleaner and easier to understand than Ruby code, and I think most Java programmers would agree. However, Python came out at the wrong time. Many developers had to make a choice between learning Python and learning Java code, and most chose Java code. Now that they've finally digested the Java syntax and are ready to add another language to their toolbox, they want tomorrow's language, not yesterday's, and that language looks to be Ruby. Most importantly, Ruby has an absolute killer app in Ruby on Rails. Its simplicity is incredibly attractive to the legion of disillusioned Java Enterprise Edition (JEE) developers.
Beyond Rails, the JRuby project offers as good or better integration with existing Java code and libraries than the other scripting languages. In fact, JRuby may well surpass the standard Ruby distribution and become the preferred platform for Ruby programmers, not just Java programmers doing a little Ruby on the side. It's that good. Python programmers will object that they've had the best aspects of JRuby for years with Jython, and they're right, but I'm talking about what will happen in 2007, not what should happen. It's sad but true: Ruby has the momentum and Python doesn't.
Other scripting languages will increasingly be relegated to the sidelines. Perl is too old-fashioned and doesn't fit modern applications very well. Groovy suffers from a lack of a clear vision and a penchant for choosing computer-science buzzwords over usability and familiarity. BeanShell, Jelly, and probably half a dozen others have never managed to attract more than a niche following. By this time next year, it will be all over but the shouting: Ruby will have become the Java programmer's scripting language of choice."
"The world would be a boring place if we only spoke one language. While the Java platform is an excellent choice for full-blown application development, it's never really fit the need for small programs or macros. Java 6 recognized this by adding the javax.script package for interoperating with scripting languages like BeanShell, Python, Perl, Ruby, ECMAScript, and Groovy as well as an invokedynamic virtual machine instruction to allow direct compilation of dynamically typed languages to the Java VM.
For 2007, my money is on Ruby, although it's not actually my personal favorite. Python code seems to me a lot cleaner and easier to understand than Ruby code, and I think most Java programmers would agree. However, Python came out at the wrong time. Many developers had to make a choice between learning Python and learning Java code, and most chose Java code. Now that they've finally digested the Java syntax and are ready to add another language to their toolbox, they want tomorrow's language, not yesterday's, and that language looks to be Ruby. Most importantly, Ruby has an absolute killer app in Ruby on Rails. Its simplicity is incredibly attractive to the legion of disillusioned Java Enterprise Edition (JEE) developers.
Beyond Rails, the JRuby project offers as good or better integration with existing Java code and libraries than the other scripting languages. In fact, JRuby may well surpass the standard Ruby distribution and become the preferred platform for Ruby programmers, not just Java programmers doing a little Ruby on the side. It's that good. Python programmers will object that they've had the best aspects of JRuby for years with Jython, and they're right, but I'm talking about what will happen in 2007, not what should happen. It's sad but true: Ruby has the momentum and Python doesn't.
Other scripting languages will increasingly be relegated to the sidelines. Perl is too old-fashioned and doesn't fit modern applications very well. Groovy suffers from a lack of a clear vision and a penchant for choosing computer-science buzzwords over usability and familiarity. BeanShell, Jelly, and probably half a dozen others have never managed to attract more than a niche following. By this time next year, it will be all over but the shouting: Ruby will have become the Java programmer's scripting language of choice."
Wednesday, October 17, 2007
Friday, June 15, 2007
Saturday, June 9, 2007
» SCRUM Митинг (daily scrum meeting)
» SCRUM Митинг (daily scrum meeting): "SCRUM - одна из гибких методологий разработки ПО. Впервые была использована в 1993 с целью улучшить продуктивность команды разработчиков, сделав упор не на качественно определенный, а на качественно контролируемый процесс разработки.
Важной частью этой методологии являются SCRUM-митинги, которые должен курировать компетентный человек - SCRUM-Master (чаще всего project manager или team lead). Такие митинги для большего эффекта нужно проводить каждый день в одно и то же время. Длительность митинга лучше ограничивать 15-30 минутами. Каждый участник проектной команды должен ответить на 3 простых вопроса:
- Что было сделано с момента предыдущего SCRUM-митинга?
- Какие возникли проблемы во время работы?
- Какими задачами буду заниматься после митинга?
После ответа на любой из этих вопросов, другие члены команды могут прокомментировать слова своего сотрудника. SCRUM-Master следит за тем, чтобы такие комментарии не затягивались и не переходили в споры. В таких случаях обсуждение некоторого вопроса SCRUM-Master откладывает на удобное для заинтересованных лиц время.
Если вы еще не проводите SCRUM-митинги внутри своей команды, вот очевидный список преимуществ этого подхода:
- За очень короткий промежуток времени project manager и все члены команды могут оценить статус проекта.
- Все возникшие проблемы решаются очень быстро так как доносятся до всех участников проекта (среди которых потенциально есть компетентные в данном вопросе люди).
- Сотрудники учатся слушать других, понимать их, а также четко выражать свои собственные мысли.
- Участники проекта учатся ставить перед собой реальные задачи и отвечать за статус их выполнения."
Google Gears: Enabling Offline Web Applications
Google Gears API Developer's Guide - Home:
"Google Gears is an open source browser extension that lets developers create web applications that can run offline.
Google Gears consists of three modules that address the core challenges in making web applications work offline.
LocalServer
Cache and serve application resources (HTML, JavaScript, images, etc.) locally
Database
Store data locally in a fully-searchable relational database
WorkerPool
Make your web applications more responsive by performing resource-intensive operations asynchronously"
"Google Gears is an open source browser extension that lets developers create web applications that can run offline.
Google Gears consists of three modules that address the core challenges in making web applications work offline.
LocalServer
Cache and serve application resources (HTML, JavaScript, images, etc.) locally
Database
Store data locally in a fully-searchable relational database
WorkerPool
Make your web applications more responsive by performing resource-intensive operations asynchronously"
Subscribe to:
Posts (Atom)
