Api Design: Key vs Session

During discussion of our new API an question come up, why session is better than a simple key.
Session concept is to have per connection object with details on customer, it's preferences, etc.
Key concept is to have passive key and number of services that uses it.
I came up with following:

Session	Key
Holds request specific data	Need to hold request specific data in api objects
More agile approach, you can make you session active, have one master instance for actions or session-specific actors	Managing class and a collection of keys are needed for two way communication
Visible list of services available	You should knew about service existence before use it
It's complex to fake system	It's easy to confuse keys

It's subject to update. Please place you thoughts about it.

Legacy system development

If you're like me, then you probably faced developing new features for legacy systems (system with no test coverage) without full understanding of source. I've done this a couple times, and want to share lessons learnt:

Legacy documentation

There are 3 sources of information about system - experienced colleagues, documentation(if exists, including javadocs and tests) and source. Fact is, you should not trust first two and use them only to understand third.
Colleagues may forget smth or think of it as of obvious thing. Tests, if they exists may be incorrect or deprecated. If documentation isn't a part of delivery, noone bothers keeping it up-to-date.

Development surroundings

Most likely new development will introduce bugs. Mine does. But not in feature you're working on. It will be some other functionality, linked with yours.
So, you need to recheck code you're depending on and recheck code, that depends on your new logic.

Also requirements is important - if you haven't understand them, you will not deliver valuable feature.

Summary

• Use all information you can get, but dont rely on it
• Only reliable source of information - code
• Check and recheck code you're depending on and code that depends on your's code
• Understand your requirements

JMeter and SLAMD for load test's in plain Java

This is article about my experience developing simple load (performance) test's for our app. 2 most famous tools were analysed: SLAMD and JMeter.

Criteria	SLAMD	Jmeter	Comments
Parameters	+	+	Ability of systems to pass parameters to Java Jobs
Distributes support	Web	Lan	How client/server communication is organized
GUI	Web	Java(bugged, see explanations)	Jmeter GUI haven't allowed my custom classes to execute. Command line worked perfectly fine
Test Plan support	No	Yes	Jmeter has more abilities for test cases creation
Test Data support	Normall	Advanced	Jmeter: CSV file native support, advanced parameters.
Documented	Good	Norm
Sources	Available	Available
Main Goal	LDAP	Web
Reporting	Advanced	Normall	SLAMD has more reporting facilities than Jmeter (Timers, Counters, internal stuff).
Reporting formats	plain, HTML, PDF	Visual, XML.
Test plan format	server internal	Xml	We can see Jmeter test plan as xml and customise it.

Windows: how to repartition or create new disk

My Computer (right click) Manage.
In the window Storage -> Disc Management.
For me and for other's folks without memory.

NT Аутентификации java приложений и tomcat с базой данных Oracle 10g

Добавление функциональности для NT Аутентификации java приложений и tomcat с базой данных Oracle 10?g.
Шаги:
1. Настроить Oracle так, чтобы он понимал Os Autentification.
Для этого:
1.0. Будут активно использованы следующие параметры:
REMOTE_OS_AUTHENT,os_authent_prefix.
Они достаются запросом: show parameter os_authent;(пользователь SYSTEM)
1.1. Установим значение флага в базе : REMOTE_OS_AUTHENT=TRUE;
Полезная ссылка: http://all-oracle.ru/content/view/?part=1&id=99
1.2. Создаём пользователя, используя? код:
CREATE USER "OPS$DOMAIN\USER" IDENTIFIED EXTERNALLY;

Надо заменить домен (DOMAIN) и пользователя (USER) на данные того, из-под кого запускается приложение. Внимание, всё вводить в верхнем регистре.
Полезная ссылка: http://www.oracle-base.com/articles/misc/OsAuthentication.php
1.3. Теперь должно работать, для проверки можно выполнить(локально): sqlplus /@SID.
Должно зайти, не спрашивая пароля и имени пользователя.
2. Установить InstantClient и добавить его в PATH и java.library.path.
Ссылка для скачивания:
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html
3. Tomcat: Изменить запись в server.xml c такой:

< resource auth="Container" driverclassname="oracle.jdbc.OracleDriver" name="jdbc/DB" password="password" type="javax.sql.DataSource" url="jdbc:oracle:thin:@host:1521:SID" username="username" maxidle="0"></resource>

на

< resource auth="Container" driverclassname="oracle.jdbc.OracleDriver" name="jdbc/AMTDB" type="javax.sql.DataSource" url="jdbc:oracle:oci:@host:1521:SID" maxidle="0"></resource>

т.е. удалить имя пользователя и пароль, заменив в URL thin на oci.
Java:

String url = "jdbc:oracle:oci:/@172.30.38.182:1521:amt";
Driver driver = new oracle.jdbc.OracleDriver();
DriverManager.registerDriver(driver);
Properties props = new Properties();
Connection conn = DriverManager.getConnection( url, props);

4. Profit!

Startup команда

Когда стартап начинается, неизвестно когда он закончится. И ключем к успеху многие считают команду. Какая команда нужна для успешного стартапа?
Команда может быть одной из двух:

• профессиональной
• увлечённой

Давайте оставим в стороне случай, в котором профессионализм (проффесиональная мотивация) и энтузиазм (мотивация сделать проект) сочетается, он идеален и достаточно редок.

Профессиональная команда

Преимущества:

• качественная работа - люди ориентированы на качество, и знают как его достигнуть
  
• высокая производительность - как следствие опыта
  
• управляемость - бизнесс-виденьем владеет только стартапер, другие не претендуют на отстаивание своего виденья
  

Недостатки:

• дороговизна - профессионалы стоят дороже. И, скорее всего, только за процент работать не будут.
  
• отсуствие критики - в случае, когда стартапер(лидер проекта) отошёл от реальности слишком далеко в виденьи проекта, ему никто не сможет помочь. Бизнесс часть оказывается в его руках, со всеми вытекающими следствиями.
  

Увлечённая команда

Преимущества:

• общее виденье - люди хотят сделать проект, помогают друг другу, общаются, делятся мнением. Бизнесс часть из-за этого мутирует, приспосабливаясь к реальности. Это даёт проекту дополнительный шанс.
  
• мотивация - команда мотивирована, она сама толкает стартапера к действиям.
• дешевизна - люди согласны работать за гораздо меньшую зарплату.
  

Недостатки:

• доля в проекте - команда будет хотеть долю в проекте.
  
• ошибки - в среде всеобщей эйфории легко не заметить очевидных вещей.
  

Частые ошибки:

не берите в команду тех, кто хочет, но не может: у кого нет времени, кто сейчас вот-вот закончит другой проект, кто не выделил в неделю и пары часов своего времени на стартап.
если вы не можете договорится в течении 2-х дней, вы не договоритесь никогда. И всё время будет потрачено на конфликты. Можно потерять друзей, деньги и мотивацию.

Вывод

Если вы уверены в своём виденьи, то стоит выбрать профессиональную команду. Если у вас есть друзья, которые готовы работать над проектом с вами, то и выбора как такового нет :)

Скрам в Бизнесе

Есть такая методика разработки программ для профессионалов, как Скрам. Скрам - это итеративный и адаптивный подход для самоорганизующихся команд. Это если в одно предложение. На сайте agilerussia можно более подробно познакомится с этим явлением.

Но не только программы можно создавать с помощью этой замечательной методологии. И новое применение, которое хочу предложить, это топ менеджемент компаний. Топы вписываются в Скрам практически идеально. Подробности дальше.

Как сейчас организовывается управляющая верхушка в практически любой компании? Да практически как получится, и политика процветает наверху, заставляя подчинённых страдать.

Зачем нужен Скрам Топам ?

Для повышения эффективности работы, прозрачности процессов, быстрого отклика рынка и организации сложного взаимодействия (проекты, в которых учавствуют все отделы/подразделения). Могу предполагать, что от таких отношений часто и зависит судьба организации. Подковровыми играми в условиях Скрама заниматься сложно, отчего его применение Скрама многим начальникам не выгодно, за то компания выигрывает.

Как применить Скрам Топам?

Достаточно просто и прямолинейно. Все начальники - это команда. Они представляют что-то и управляют чем-то. Для чего? Решать директору или рынку, тут кого выберут за главного :) В списке набор вопросов, возможно какая-то стратегия развиния - чем не эпик в User Stories ? Можно создавать проекты и ставить конкретные цели на фиксированнное время. И достигать их всем вместе, сообща. По крайней мере, каждый из топов будет знать что компания сейчас делает, что может сделать и чего не может, а это позволит управлятся более оптимально. Наблюдать и адаптироваться, а также координировать действия вместе по согласованному плану. Достаточно просто звучит, но нужен Скрам Мастер, чтобы достичь такого единства :)

Вместо заключения

Я бы хотел работать в такой компании, ведь подчинённые не оказывались бы крайними при таких правилах игры, что безусловно приятно.
Теперь СкрамМастера и консультанты могут открывать для себя новые рынки, я полагаю ;)