Давать на выполнение задание имхо правильно, потому что оценить человека можно точнее, чем на словах.
Но со стороны претендента вполне оправданно сделать и сообщить приблизительную оценку времени задачи, и далее поступать согласно своим принципам; я, например, считаю, что результат выполнения серьезного задания должен быть оплачен, о чем честно предупреждаю.
А вот насчет компаний — не отчаивайтесь, есть и небольшие, но с хорошо поставленным процессом, и даже в провинции. Сам благодарен одной такой, за то, что, по большому счету, сделала из меня программиста.
Краткое ИМХО: я всецело за то, чтобы любить свою работу, но если вы не можете сконвертировать саморазвитие в пользу проекту и бизнесу, то платить вам за это не стоит.
Автор прав в том, что его не устраивает исполнительство. Потому что зачастую исполнительство — это синоним «пофигизма». Именно против этого он и протестует, и я его понимаю — на моей работе в соседней команде IT-исполнители в рабочее время торгуют акциями и ценными бумагами через интернет, обсуждают коллекционирование монет на форумах, следят за новостями фотоиндустрии. В тоже самое время www.martinfowler.com неинтересен ни одному.
По большому счету, им все равно, чем заниматься, и в IT они только потому, что здесь относительно высоко платят, кормят, и приятно сидеть в офисе и читать новости.
С другой стороны, если вы, автор, хотите новых технологий ради новых технологий — вы не правы. Если вы хотите прикрутить AJAX только потому, что это модно и ново — вы не правы. Если вы хотите построить проект на WCF, потому что незнакомы с ним и решили «познать новое» (за деньги заказчика) — вы не правы.
Вообразите, что вы хирург. Хирурги не пытаются резать ту опухоль, про которую они не знают. Вначале они изучают ее и тренируются на образцах.
Энтузиазм — это хорошо, многое держится на нем. Хотение лучшего — это тоже хорошо.
Нужно только направлять их в русло, обеспечивающее выполнение тех задач, которые перед вами стоят, а не абстрактного «саморазвития» ради него самого.
Первый и второй слишком оптически шумные, у последнего слева большое пространство, начинающееся почти с самого верха. Это непривычно, потому что глаза обычно именно слева — ищут, чтоб такое прочесть :)
Теперь что касается последнего.
Картинки в постах на последнем дизайне одинакового размера — я сильно сомневаюсь, что в реальности так будет. Поиграйте с размерами картинок и взгляните, как будет смотреться. Маленькие картинки с рейтингом слева от постов чересчур закарамеленные.
Ну так пока все ) Извините, если дизайнера обидел чем )
Даже той единственной причины, что последний дизайн заполнен реальными данными, а не «рыбой», хватило бы, чтобы выбрать его. Только слайдер снизу убрать — он имхо бестолков, хабрапереключатель получше будет.
Отвечу сразу и про уровни, и merge; только сильно не ругайте, если чушь несу :)
Классические транзакции (в реляционных БД) имеют некоторую область действия — «захват» данных при выполнении. В ООП-транзакциях, где обновляются графы объектов, транзакции должны «захватывать» объект и/или его соседей в графе. Уровнем транзакции (условно) будет глубина связей, на которую распространяется действие транзакции.
Merger в таком случае будет, например, действовать как маска — кто из соседей или какие из полей объекта игнорируются при захвате.
Не, дык HQL по большому счету покласть на маппинги, как AST он сам по себе весьма интересен, и можно сделать так, что уши таблиц и прочая SQL не будет нигде торчать.
Ох, блин, счас я нафантазирую :) Как тут принято писать, в комнате жарко, чашка на столе полна ацетона, его пары помогают увидеть нижеследующее.
Если я правильно понимаю, все эти уровни изоляции были введены как компромисс между производительностью и «здравым смыслом» :) Соответственно,
— шаг 1 — убираем промежуточные уровни изоляции: данные либо полностью непротиворечивы (в терминах объектов), либо данных нет; за этим следит инфраструктура, а не пользователь, который счас должен почти «угадывать» уровень изоляции и делать выкладки;
— шаг 2 — добавляем самонастраивающийся арбитр транзакций: пусть начинает с самого высокого уровня изоляции (версии), но постепенно «ослабляет болты» на основании статистики запросов; хинты ему приветствуются — это как раз то, что можно программисту потюнинговать, ибо самописный арбитр — это для тех, кто хочет — ррраз! — взять и обуглить себе мозг.
— шаг 3 — SQL в топку, даешь HQL и Linq, раз уж у вас .net; ну или Fluent QueryBuilder, НЕ основанный на склейке строк :)
— шаг 4 — Читабельный журнал транзакций; в прочем, это уже к истории относится, там и отвечу.
— шаг 5 — Раз уж у нас версии, то должен быть user-defined merger данных (может, мы такие извращенцы, что полная изоляция данных нас не устраивает), выбранный из предоставленных или «съемный»
Фуух, я бы и дальше молотил, но ацетон рассеялся… пока что все, не принимайте сказанное всерьез :)
Для электронного магазина a la быдлопхп (sic!) с минимумом апдейтов можно обойтись и блокировками. Имхо.
А вообще я думаю, что для объектной БД стоит вовсе пересмотреть концепцию транзакций.
Ну, если интересны мои «фантазии» по этому поводу, то я думаю, что в будущем будет не просто «уровень изоляции», а настройки стратегии для snapshot factory + change merger, позволяющие выбрать нужный уровень безопасности.
От использования php в веб для сайтов, работающих с деньгами клиента, не останавливает даже отсутствие там нормальной детерминистической обработки ошибок.
Пор поводу «версионность или блокировки» — по ситуации. Это как ответ на вопрос — что лучше, бульдозер или самолет :)
При обычных нагрузках хватает обычных блокирующих механизмов, но если нужно обеспечить отсуствие «затыка» для многих параллельных транзакций, тем более — на уровне RepeatableRead и выше, ИМХО стоит посмотреть на версионные.
А кто же им, по-вашему, нужен?
Но со стороны претендента вполне оправданно сделать и сообщить приблизительную оценку времени задачи, и далее поступать согласно своим принципам; я, например, считаю, что результат выполнения серьезного задания должен быть оплачен, о чем честно предупреждаю.
А вот насчет компаний — не отчаивайтесь, есть и небольшие, но с хорошо поставленным процессом, и даже в провинции. Сам благодарен одной такой, за то, что, по большому счету, сделала из меня программиста.
Автор прав в том, что его не устраивает исполнительство. Потому что зачастую исполнительство — это синоним «пофигизма». Именно против этого он и протестует, и я его понимаю — на моей работе в соседней команде IT-исполнители в рабочее время торгуют акциями и ценными бумагами через интернет, обсуждают коллекционирование монет на форумах, следят за новостями фотоиндустрии. В тоже самое время www.martinfowler.com неинтересен ни одному.
По большому счету, им все равно, чем заниматься, и в IT они только потому, что здесь относительно высоко платят, кормят, и приятно сидеть в офисе и читать новости.
С другой стороны, если вы, автор, хотите новых технологий ради новых технологий — вы не правы. Если вы хотите прикрутить AJAX только потому, что это модно и ново — вы не правы. Если вы хотите построить проект на WCF, потому что незнакомы с ним и решили «познать новое» (за деньги заказчика) — вы не правы.
Вообразите, что вы хирург. Хирурги не пытаются резать ту опухоль, про которую они не знают. Вначале они изучают ее и тренируются на образцах.
Энтузиазм — это хорошо, многое держится на нем. Хотение лучшего — это тоже хорошо.
Нужно только направлять их в русло, обеспечивающее выполнение тех задач, которые перед вами стоят, а не абстрактного «саморазвития» ради него самого.
Первый и второй слишком оптически шумные, у последнего слева большое пространство, начинающееся почти с самого верха. Это непривычно, потому что глаза обычно именно слева — ищут, чтоб такое прочесть :)
Теперь что касается последнего.
Картинки в постах на последнем дизайне одинакового размера — я сильно сомневаюсь, что в реальности так будет. Поиграйте с размерами картинок и взгляните, как будет смотреться. Маленькие картинки с рейтингом слева от постов чересчур закарамеленные.
Ну так пока все ) Извините, если дизайнера обидел чем )
А логотип слева вверху у него классно-узнаваемый.
Даже той единственной причины, что последний дизайн заполнен реальными данными, а не «рыбой», хватило бы, чтобы выбрать его. Только слайдер снизу убрать — он имхо бестолков, хабрапереключатель получше будет.
Классические транзакции (в реляционных БД) имеют некоторую область действия — «захват» данных при выполнении. В ООП-транзакциях, где обновляются графы объектов, транзакции должны «захватывать» объект и/или его соседей в графе. Уровнем транзакции (условно) будет глубина связей, на которую распространяется действие транзакции.
Merger в таком случае будет, например, действовать как маска — кто из соседей или какие из полей объекта игнорируются при захвате.
Исторические данные — различные: история изменений, заточенная под OLAP и отложенный OLAP, история транзакций под тем же соусом.
С Oracle и DB2 сильно плотно не работал, поэтому не могу ничего сказать, как это там :( В MsSQL точно никак :)
Если ваш SQL очень близок, то это отлично.
Если я правильно понимаю, все эти уровни изоляции были введены как компромисс между производительностью и «здравым смыслом» :) Соответственно,
— шаг 1 — убираем промежуточные уровни изоляции: данные либо полностью непротиворечивы (в терминах объектов), либо данных нет; за этим следит инфраструктура, а не пользователь, который счас должен почти «угадывать» уровень изоляции и делать выкладки;
— шаг 2 — добавляем самонастраивающийся арбитр транзакций: пусть начинает с самого высокого уровня изоляции (версии), но постепенно «ослабляет болты» на основании статистики запросов; хинты ему приветствуются — это как раз то, что можно программисту потюнинговать, ибо самописный арбитр — это для тех, кто хочет — ррраз! — взять и обуглить себе мозг.
— шаг 3 — SQL в топку, даешь HQL и Linq, раз уж у вас .net; ну или Fluent QueryBuilder, НЕ основанный на склейке строк :)
— шаг 4 — Читабельный журнал транзакций; в прочем, это уже к истории относится, там и отвечу.
— шаг 5 — Раз уж у нас версии, то должен быть user-defined merger данных (может, мы такие извращенцы, что полная изоляция данных нас не устраивает), выбранный из предоставленных или «съемный»
Фуух, я бы и дальше молотил, но ацетон рассеялся… пока что все, не принимайте сказанное всерьез :)
Работа с версиями — snapshot isolation вас не устраивает, или вы о чем-то еще?
Тогда я помечтаю еще и об «историческом» хранилище «из коробки» :)
А вообще я думаю, что для объектной БД стоит вовсе пересмотреть концепцию транзакций.
Ну, если интересны мои «фантазии» по этому поводу, то я думаю, что в будущем будет не просто «уровень изоляции», а настройки стратегии для snapshot factory + change merger, позволяющие выбрать нужный уровень безопасности.
Пор поводу «версионность или блокировки» — по ситуации. Это как ответ на вопрос — что лучше, бульдозер или самолет :)
При обычных нагрузках хватает обычных блокирующих механизмов, но если нужно обеспечить отсуствие «затыка» для многих параллельных транзакций, тем более — на уровне RepeatableRead и выше, ИМХО стоит посмотреть на версионные.
А вот про отсутствие транзакций — совсем плохо:(
Боюсь, что смысла в такой БД сейчас, кроме академического, нет; пусть даже она и «украдена».
Главное, чтобы все так и не осталось на уровне embedded storage. Будем ждать билдов с транзакциями.