Нарешті відбувся реліз IntellijIDEA 9.0.
Для мене це було неочікувано, хоча користуюся EAP'ами вже давно. Перейшов через підтримку FreeMarker та Velocity. А пізніше добавилась перевірка коректності слів по словнику, відчутно покращилася швидкодія в останніх EAP версіях, можливість назначати кольори окремим групам файлів, потім добавилося code folding для дженериків та анонімних класів та багато іншого. Цікаво також, що є можливість генерити діаграми класів, діаграми змінених класів, підключення до Jira та YouTrack для роботи із тасками.
Версія 9.0 вийшла в двох редакція: повнофункціональна Ultimate Edition з підтримкою JavaEE та великої кількості плагінів, а також безкоштовної з відкритим кодом Community Edition.
Корисні посилання:
1. IntellijIDEA blog
2. IDEA what's new
Задумався я над UML. Вчу студентів, що це дуже корисна річ, часто використовується в реальному світі. Допомогає не тільки спроектувати програму, але і донести свою думку до інших, зрозуміти чужу програму; є важливою частина документації.
І справді, UML буває корисним для того, щоб спроектувати програму, якщо це взагалі можливо зробити в повній мірі. Донести думку до інших за допомогою UML - річ також нетривіальна, хоча все залежить. Щодо технічної документації, то я прихильник думки, що найкраща документація - це сам код програми (доречі тут можна почитати про це більше).
А ще часто доводиться чути думки, що UML - це зайве, що все в голові можна спроектувати, і при цьому особливо "ясно видно динаміку". Інші не розуміють, навіщо ці квадратики та кружочки; a це й чоловічок (которий актор, чи то пак актант) взагалі смішно виглядає. Інші і не знають про це або знають, але не пробували.
Кожному своє. Я ж використовую UML, точніше ту частину, що мені справді допомагає. Я не пробую спроектувати всю систему, бо зазвичай це є неможливо через складність, величину системи чи плинність вимог. І звичайно я не завжди використовую UML, тільки коли це потрібно.
Натомість при розробці певної функції програми, що виходить поза межі стандартних шаблонів та правил проекту не можу обійтися без діаграм випадків використання, класів та послідовностей. Цих трьох діаграм для мене достатньо.
Спершу визначити список випадків використання та їх сценарії, як результат визначити список додаткових питань та білих плям в специфікації. Після цього вже на основі прецендентів паралельно будуються діаграми класів та послідовностей. Роблю це все на листочку або на боарді. Зазвичай, починаю з основного і закінчую другорядними класами та зв'язками. Найцікавіше потім переробити систему, починаючи з найпростіших другорядних класів та закінчуючи основними. Наступне просіювання починається при написанні коду. Знову ж таки, писати починаю з найпростіших і/або другорядних класів. Це не тільки дає час подумати над удосконаленням основних класів та інтерфейсів, а також прощупати це все ручками в коді, визначити білі плями, розбіжності та несходження.
Ось так вона, думка, спочатку матеріалізується на бумазі, відточується, потім перетворюється в код, і ще раз відточується.
І взагалі, дуже цікаву книжку Крега Лармана Применение UML 2.0 и шаблонов проектирования. Якщо є перша версія, то можна почитати її, як це колись зробив я. Раджу всім, особливо студентам, що хочуть зрозуміти принципи проектування та розробки ОО програмного забезпечення.
І справді, UML буває корисним для того, щоб спроектувати програму, якщо це взагалі можливо зробити в повній мірі. Донести думку до інших за допомогою UML - річ також нетривіальна, хоча все залежить. Щодо технічної документації, то я прихильник думки, що найкраща документація - це сам код програми (доречі тут можна почитати про це більше).
А ще часто доводиться чути думки, що UML - це зайве, що все в голові можна спроектувати, і при цьому особливо "ясно видно динаміку". Інші не розуміють, навіщо ці квадратики та кружочки; a це й чоловічок (которий актор, чи то пак актант) взагалі смішно виглядає. Інші і не знають про це або знають, але не пробували.
Кожному своє. Я ж використовую UML, точніше ту частину, що мені справді допомагає. Я не пробую спроектувати всю систему, бо зазвичай це є неможливо через складність, величину системи чи плинність вимог. І звичайно я не завжди використовую UML, тільки коли це потрібно.
Натомість при розробці певної функції програми, що виходить поза межі стандартних шаблонів та правил проекту не можу обійтися без діаграм випадків використання, класів та послідовностей. Цих трьох діаграм для мене достатньо.
Спершу визначити список випадків використання та їх сценарії, як результат визначити список додаткових питань та білих плям в специфікації. Після цього вже на основі прецендентів паралельно будуються діаграми класів та послідовностей. Роблю це все на листочку або на боарді. Зазвичай, починаю з основного і закінчую другорядними класами та зв'язками. Найцікавіше потім переробити систему, починаючи з найпростіших другорядних класів та закінчуючи основними. Наступне просіювання починається при написанні коду. Знову ж таки, писати починаю з найпростіших і/або другорядних класів. Це не тільки дає час подумати над удосконаленням основних класів та інтерфейсів, а також прощупати це все ручками в коді, визначити білі плями, розбіжності та несходження.
Ось так вона, думка, спочатку матеріалізується на бумазі, відточується, потім перетворюється в код, і ще раз відточується.
І взагалі, дуже цікаву книжку Крега Лармана Применение UML 2.0 и шаблонов проектирования. Якщо є перша версія, то можна почитати її, як це колись зробив я. Раджу всім, особливо студентам, що хочуть зрозуміти принципи проектування та розробки ОО програмного забезпечення.
Apache JMeter
Попрацював сьогодні трохи з JMeter. Давно знаю про цю програму, давно хотів навчитися її використовувати, але до сьогодні якось не складалося.
Загальне враження від неї позитивне: простий інтерфейс, зручне представлення тесту у вигляді дерева, чітко визначений життєвий цикл тесту та послідовність виконання кожного елементу тесту дозволяют швидко накидати та запустити тест. А набір лістенерів дозволяють представити отримані дані зберегти та представити у зручному вигляді: таблиці із детальними та середніми значеннями, графіки тощо.
Звичайно необовязково запускати JMeter у візуальному режимі. Можна також скористатися режимом командного рядка або сервера для розприділеного тестування. Включивши навантажувальні тести JMeter в процес збірки певних версії проекту (наприклад, тестових версій, чи спеціальних щотижневих версій), можна контролювати метрику швидкодії програми. І все це безкоштовно.
Сьогодні використовувати її проте прийшлося тільки для перевірки середньої швидкодії програми при різних навантаженнях на різних серверів. Висновок: трохи треба попрацювати над швидкодією окремих речей. А ще планую підготувати декілька простих тестових випадків і періодично знімати метрики зміни швидкодії та масштабування в процесі розробки.
Особливо цікаво також було порівняти зібраних даних з серверів та мого ноутбука. Висновок: настав час придбати собі нового звіра :).
Корисні посилання:
1. JMeter User Manual
2. http://www.scribd.com/doc/7499267/Load-Testing-With-JMeter
3. JMeter tips
Загальне враження від неї позитивне: простий інтерфейс, зручне представлення тесту у вигляді дерева, чітко визначений життєвий цикл тесту та послідовність виконання кожного елементу тесту дозволяют швидко накидати та запустити тест. А набір лістенерів дозволяють представити отримані дані зберегти та представити у зручному вигляді: таблиці із детальними та середніми значеннями, графіки тощо.
Звичайно необовязково запускати JMeter у візуальному режимі. Можна також скористатися режимом командного рядка або сервера для розприділеного тестування. Включивши навантажувальні тести JMeter в процес збірки певних версії проекту (наприклад, тестових версій, чи спеціальних щотижневих версій), можна контролювати метрику швидкодії програми. І все це безкоштовно.
Сьогодні використовувати її проте прийшлося тільки для перевірки середньої швидкодії програми при різних навантаженнях на різних серверів. Висновок: трохи треба попрацювати над швидкодією окремих речей. А ще планую підготувати декілька простих тестових випадків і періодично знімати метрики зміни швидкодії та масштабування в процесі розробки.
Особливо цікаво також було порівняти зібраних даних з серверів та мого ноутбука. Висновок: настав час придбати собі нового звіра :).
Корисні посилання:
1. JMeter User Manual
2. http://www.scribd.com/doc/7499267/Load-Testing-With-JMeter
3. JMeter tips
Subscribe to:
Posts (Atom)