Заняться фрилансом меня заставило наличие свободного времени на работе. Собственно я и не уходил никуда. Я нагло сижу на рабочем месте и кропаю проекты под заказ. При этом не чувствую себя негодяем или вором по следующим причинам:
1. Я успеваю сделать свою работу в 100 раз быстрее, чем это делают остальные. У меня куча свободного времени, почему бы его не потратить на себя?
2. В Европе в ИТ компаниях для специалиста есть финансовый потолок. То есть даже если ты в 10 раз эффективнее, и на тебе по сути держится весь проект, зарплату тебе не увеличат даже в 2 раза (реально можешь просить 10%-15%). В Европе лучше нанять в проект еще 10 ненужных работников, чем увеличить зарплату специалистам.
3. Измерять работу в человекочасах попросту глупо, ибо отнимает всякую мотивацию у работников. Как говорится, солдат спит, а служба идет. Работник должен быть всегда заинтересован в результатах.
Тормозит со включенными эффектами рабочего стола. Попробуйте отключить compiz, а для этого нужно не просто снять галочку, а залогиниться в Failsafe GNOME — и будет летать.
Не совсем понимаю как в первая функция запрещает изменение содержимого передаваемого массива. То есть const int[] a предохраняет изменение массива (или только ссылки на него?) в контексте функции, но не за ее пределами. Поэтому при асинхронном выполнений возникнет несоответствие «concurrent array modification».
Вообще передача ссылочных типов в «чистые» функции нарушает их изолированность от контекста выполнения. Единственный вариант сохранения изоляции — это делать глубокие unmodified копии передаваемых объектов. Иначе, для пущей чистоты, придется запретить ссылки.
Старый добрый ООП для business layer-а еще никто не отменял. Достоинство: на основе написанных компонентов при минимальном изменении можно кастомизировать логику. Недостаток: усложняется инъекция новых объектов, решается при помощи фреймворков типа Spring.
1. Дураки. Они мешают нам жить и работать. Когда дурак один, его игнорируют. Когда же их много, они формируют большинство и способны забить любую рациональную идею (поскольку не в силах понять о чем идет речь). Дурак может часами рассуждать об оптимизации одного цикла или условия. На большее он просто не способен. Как правило дурак не генерирует своих мыслей, все его мысли — это понятые им обрывки чужих рассуждений.
2. Мудаки. Это по сути гиперактивный дурак. Лозунг мудака — чем сложнее, тем лучше. В присутствии мудака ваш проект обрастет говном до неподъемного состояния быстрее, чем вы успеете его доделать. В ход пойдут всевозможные фреймворки и тулзы, причем чем экзотичней тулза, тем круче выглядит проект.
> Если разогнать в одной такой «трубке» электроны, а в другой — позитроны…
Ага. Только и всего. И именно на такую плевую вещь было потрачено 6 миллиардов и гигаватты энергии. Вопрос не в том, чтобы разогнать, а в том КАК СИЛЬНО разогнать!
Старые версии Linux не поддерживали Posix Threads, поэтому многопоточность реализовывалась банальным fork с запуском дочернего процесса. Для JVM это было прозрачно, но в системе болталась куча процессов, и запуск запуск треда занимал значительное время.
Обычная Sun JRE использует native threads. Однако в реализации под Solaris по желанию можно использовать библиотеку green threads самой ОС. В этом случае многопоточность реализуется по правилу m: n, то есть m native threads обслуживают по n green threads. Причем все это делается прозрачно для написанного кода. Некоторые другие имплементации JVM тоже поддерживают green threads (напр. JRockit).
Green threads уместно использовать в задачах с большим числом потоков. Классической задачей из книжки является тредовый сервер. На каждый установленный с клиентом коннекшн открывается новый тред, который обрабатывает запросы. Проблема в том, что при большом числе открытых потоков (>1000) планировщик задач ОС тратит основную часть времени только на бесполезное переключение между ними, несмотря на то, что сами потоки большую часть времени «спят» при чтении из сокета. Спасают green threads, где виртуальные потоки вешаются на один native thread.
Как работают green threads? Поскольку работает только один native thread, то в каждый момент времени может выполняться только один поток из виртуальных потоков. Переключение между потоками производится в момент, когда поток выполняет блокирующую операцию (синхронизация, I/O, sleep(), wait(), etc...). Более того, некоторые JVM искусственно вставляют в код потока операции переключения. В модели m: n после блокирующей операции виртуальный поток может быть продолжен другим m из имеющихся native потоков, поэтому выполнение всех потоков в этой модели происходит более-менее равномерно.
P.S. Более удачное решение для сервера в java является non-blocking I/O + thread pool
P.P.S. карма не позволяет писать статьи… :(
Наивный чукотский юноша!
Клиенту не нужен абстрактный хороший работник. Как правило клиент ищет конкретных специалистов, чтобы заткнуть дырку в штате/проекте. Поэтому имя/фамилия и список освоенных технологий будет вполне достаточно для резюме. Все остальное служит для того, чтобы клиент выбрал вас среди конкурентов. Для этого самый весомый показатель — портфолио и реализованные проекты. Все остальное — полная фигня, которая служит для самооправдания, типа «почему меня не взяли — наверное где-то в слове ошибку сделал».
Вычтите стоимость времени простоя компании из налогов, которые Вы платите государству.
Если государство не в состоянии построить электростанции и обеспечить потребности населения в элементарном — валите оттуда и нехрен его любить. Потому что сегодня электричество, завтра — вода, послезавтра — жратва по талонам.
>1. Какие проблемы с оплатой чаще всего возникают у вас?
Клиент извивается как уж на сковородке, и клянется заплатить, но деньги на счет не приходят. Приходится тратить много сил и нервов на «выбивание».
> 2. Что говорят клиенты, задерживающие оплату?
Пытаются добавить работы многочисленными «улучшениями». Типа, вот нам необходимо сделать там-то еще такую штучку и мы вам сразу заплатим.
> 3. Как вы решаете эти проблемы?
Разбиваем работу и оплату на несколько частей по следующим концептам:
Особо важен переход между 3 и 4. Все поставляемые беты ЗАЩИЩЕНЫ кодом, препятствующим их дальнейшее использование (например, лимит по времени). При принятии клиентом проекта производится оплата, после которой ему предоставляется релиз, с которого снят защитный код (плюс документация, материалы, анализ и т.д. и т.п.)
Измерение работы в человекочасах не всегда приемлемо. Если мы говорим про работу землекопов, то да — по большей части метры канавы линейно зависят от человекочасов. Но КРЕАТИВНАЯ РАБОТА (коей является работа дизайнера, программиста, архитектора) не может измеряться в человекочасах, и даже не может быть нормально оценена.
С точки зрения простоты триггеры — не очень удачное решение, поскольку запутывают структуру и логику базы данных. Если требуется сделать нечто больше, чем update поля, лучше использовать хранимую процедуру. В идеале, любое изменяющее действие над базой должно проходить через процедуру, а не напрямую в таблицы. Таким образом контролируется все валидные действия бизнес тайера и обеспечивается целостность.
Все это накаление обстановки с целью выбить гранты на дальнейшие исследования.
Не надо путать СРВ с хроническим утомлением. Второе получается в результате недосыпа, стрессов, отсутствия необходимого отдыха - ритма современной жизни. СРВ как правило появляется уже в детском возрасте, а не приобретается в процессе жизнедеятельности, и связано, как считают многие, с недостатком определеных веществ в организме. Между прочим, многие талантливые люди страдали СРВ, что не помешало им создать великие творения.
Да, сегодня человеческий мозг обрабатывает в 3-4 раза больше информации, чем 50 лет назад. Но в итоге общество адаптируется. Люди научатся фильтровать информацию - отделять "сигналы" от общего "шума".
> То есть ничего принципиального нового не появляе тся, а сложность и объём возрастает? Всё это можно было сделать в три раза меньше используя только базовое знаение SQL.
Вцелом Вы правы. Только это называется прогресс ))) Идеи выходят на более абстрактный уровень и отрываются от конкретики. Например, считать на пальцах проще и практичней, чем в уме, но дольше. Управлять трактором сложнее, чем лошадью, но для обработки земли трактор производительней...
2. ООП здесь не при чем. Зачем делать каждый раз то, что машина должна уметь делать сама (я имею ввиду написание запросов). Структура данных ей известна, необходимые данные - тоже. В чем проблема?
3. Это был только пример. В Hibernate 3 можно обойтись без XML при помощи аннотаций (см. коментарии выше). Как говорится, тяжело в учении - легко в бою. Один раз попотев над структурой и меппингом, манипуляция с данными становится очень простой и наглядной.
4. Здесь мы говорим не о самом наследовании, а о его персистенции в базе данных. Наследование-то вы сделали, а кто сохранять его будет?
> Нет, правда, скажите, что Вы не серьёзно!!! Или хотите, я вам продам за сто тыщ мульёнов идею, как не писать в каждом методе SQL код? :)))))
Посмотрите коммент от пользователя Regis.
http://habrahabr.ru/blog/java/47258.html#comment1011773
Если Вы мне предложите что-нибудь проще и короче, то я возьму все свои слова обратно.
1. Любая предметная область состоит из сущностей и отношений между ними, а не из каши атрибутов. Поэтому оперировать объектами удобнее и правильней, нежели полями.
2. В ORM вы определяете структуру данных и отношения ОДИН РАЗ, и не задумываетесь при выборке данных. В SQL же вы в каждом запросе цепляете абсолютно глупый компот из JOIN и заново указываете связи (несмотря на то, что структура уже определена DDL).
3. Hibernate-реализация не зависит от движка БД. Чтобы перейти на новый движок вам не нужно будет перелопачивать тонны кода, достаточно поменять пару строчек в конфигурации. Более того, к Hibernate можно прикрутить сторонние движки, например Lucene.
4. Hibernate позволяет в простой форме реализовать наследование.
5. Кеш данных, кеш второго уровня и прочие вкусности.
6. При переименовании таблиц/полей не придется апдейтить все запросы (количество которых может быть вырасти до тысяч), а достаточно лишь поменять меппинг.
А теперь самое главное:
bus.getDrivers() намного проще, чем
SELECT * FROM drivers, busdriver WHERE drivers.driver_id = busdriver.driver_id AND bus_id = xxx
В добавок, в IDEs типа Eclipse при вводе "bus." вылезет полный список полей объекта. В SQL же запросах постоянно придется консультировать правильное написание полей в структуре данных.
Как это ни странно, Hibernate плохо приспособлен для функционирования в среде веб, особенно если вы не пользуетесь EJB контейнером. Проблема в том, что связанные поля и коллекции с lazy fetching не могут использоваться за пределами сессии. Например если в примере автора поле Bus.drivers замепить как lazy, то
BusDAO.getBusById( ... ).getDrivers().get( ... )
не выдаст водителя автобуса, поскольку обращение к полю drivers (и фетчинг коллекции) лежит за пределами сессии. Это происходит всегда, когда вы используете, например, любой mvc фреймворк. В этом случае фетчинг lazy полей может происходить не только в action, но и в момент рендеринга страницы.
Как возможное решение можно написать фильтр для Tomcat, который до обработки запроса открывает новую hibernate-сессию и записывает ее как атрибут в объект request, а после обработки делает commit и закрывает ее.
1. Я успеваю сделать свою работу в 100 раз быстрее, чем это делают остальные. У меня куча свободного времени, почему бы его не потратить на себя?
2. В Европе в ИТ компаниях для специалиста есть финансовый потолок. То есть даже если ты в 10 раз эффективнее, и на тебе по сути держится весь проект, зарплату тебе не увеличат даже в 2 раза (реально можешь просить 10%-15%). В Европе лучше нанять в проект еще 10 ненужных работников, чем увеличить зарплату специалистам.
3. Измерять работу в человекочасах попросту глупо, ибо отнимает всякую мотивацию у работников. Как говорится, солдат спит, а служба идет. Работник должен быть всегда заинтересован в результатах.
Вообще передача ссылочных типов в «чистые» функции нарушает их изолированность от контекста выполнения. Единственный вариант сохранения изоляции — это делать глубокие unmodified копии передаваемых объектов. Иначе, для пущей чистоты, придется запретить ссылки.
2. Мудаки. Это по сути гиперактивный дурак. Лозунг мудака — чем сложнее, тем лучше. В присутствии мудака ваш проект обрастет говном до неподъемного состояния быстрее, чем вы успеете его доделать. В ход пойдут всевозможные фреймворки и тулзы, причем чем экзотичней тулза, тем круче выглядит проект.
Ага. Только и всего. И именно на такую плевую вещь было потрачено 6 миллиардов и гигаватты энергии. Вопрос не в том, чтобы разогнать, а в том КАК СИЛЬНО разогнать!
Старые версии Linux не поддерживали Posix Threads, поэтому многопоточность реализовывалась банальным fork с запуском дочернего процесса. Для JVM это было прозрачно, но в системе болталась куча процессов, и запуск запуск треда занимал значительное время.
Обычная Sun JRE использует native threads. Однако в реализации под Solaris по желанию можно использовать библиотеку green threads самой ОС. В этом случае многопоточность реализуется по правилу m: n, то есть m native threads обслуживают по n green threads. Причем все это делается прозрачно для написанного кода. Некоторые другие имплементации JVM тоже поддерживают green threads (напр. JRockit).
Green threads уместно использовать в задачах с большим числом потоков. Классической задачей из книжки является тредовый сервер. На каждый установленный с клиентом коннекшн открывается новый тред, который обрабатывает запросы. Проблема в том, что при большом числе открытых потоков (>1000) планировщик задач ОС тратит основную часть времени только на бесполезное переключение между ними, несмотря на то, что сами потоки большую часть времени «спят» при чтении из сокета. Спасают green threads, где виртуальные потоки вешаются на один native thread.
Как работают green threads? Поскольку работает только один native thread, то в каждый момент времени может выполняться только один поток из виртуальных потоков. Переключение между потоками производится в момент, когда поток выполняет блокирующую операцию (синхронизация, I/O, sleep(), wait(), etc...). Более того, некоторые JVM искусственно вставляют в код потока операции переключения. В модели m: n после блокирующей операции виртуальный поток может быть продолжен другим m из имеющихся native потоков, поэтому выполнение всех потоков в этой модели происходит более-менее равномерно.
P.S. Более удачное решение для сервера в java является non-blocking I/O + thread pool
P.P.S. карма не позволяет писать статьи… :(
Клиенту не нужен абстрактный хороший работник. Как правило клиент ищет конкретных специалистов, чтобы заткнуть дырку в штате/проекте. Поэтому имя/фамилия и список освоенных технологий будет вполне достаточно для резюме. Все остальное служит для того, чтобы клиент выбрал вас среди конкурентов. Для этого самый весомый показатель — портфолио и реализованные проекты. Все остальное — полная фигня, которая служит для самооправдания, типа «почему меня не взяли — наверное где-то в слове ошибку сделал».
Если государство не в состоянии построить электростанции и обеспечить потребности населения в элементарном — валите оттуда и нехрен его любить. Потому что сегодня электричество, завтра — вода, послезавтра — жратва по талонам.
Клиент извивается как уж на сковородке, и клянется заплатить, но деньги на счет не приходят. Приходится тратить много сил и нервов на «выбивание».
> 2. Что говорят клиенты, задерживающие оплату?
Пытаются добавить работы многочисленными «улучшениями». Типа, вот нам необходимо сделать там-то еще такую штучку и мы вам сразу заплатим.
> 3. Как вы решаете эти проблемы?
Разбиваем работу и оплату на несколько частей по следующим концептам:
1. Предоплата.
2. Работающий макет.
3. Полнофункциональная бета.
4. Релиз.
Особо важен переход между 3 и 4. Все поставляемые беты ЗАЩИЩЕНЫ кодом, препятствующим их дальнейшее использование (например, лимит по времени). При принятии клиентом проекта производится оплата, после которой ему предоставляется релиз, с которого снят защитный код (плюс документация, материалы, анализ и т.д. и т.п.)
Не надо путать СРВ с хроническим утомлением. Второе получается в результате недосыпа, стрессов, отсутствия необходимого отдыха - ритма современной жизни. СРВ как правило появляется уже в детском возрасте, а не приобретается в процессе жизнедеятельности, и связано, как считают многие, с недостатком определеных веществ в организме. Между прочим, многие талантливые люди страдали СРВ, что не помешало им создать великие творения.
Да, сегодня человеческий мозг обрабатывает в 3-4 раза больше информации, чем 50 лет назад. Но в итоге общество адаптируется. Люди научатся фильтровать информацию - отделять "сигналы" от общего "шума".
Вцелом Вы правы. Только это называется прогресс ))) Идеи выходят на более абстрактный уровень и отрываются от конкретики. Например, считать на пальцах проще и практичней, чем в уме, но дольше. Управлять трактором сложнее, чем лошадью, но для обработки земли трактор производительней...
2. ООП здесь не при чем. Зачем делать каждый раз то, что машина должна уметь делать сама (я имею ввиду написание запросов). Структура данных ей известна, необходимые данные - тоже. В чем проблема?
3. Это был только пример. В Hibernate 3 можно обойтись без XML при помощи аннотаций (см. коментарии выше). Как говорится, тяжело в учении - легко в бою. Один раз попотев над структурой и меппингом, манипуляция с данными становится очень простой и наглядной.
4. Здесь мы говорим не о самом наследовании, а о его персистенции в базе данных. Наследование-то вы сделали, а кто сохранять его будет?
> Нет, правда, скажите, что Вы не серьёзно!!! Или хотите, я вам продам за сто тыщ мульёнов идею, как не писать в каждом методе SQL код? :)))))
Посмотрите коммент от пользователя Regis.
http://habrahabr.ru/blog/java/47258.html#comment1011773
Если Вы мне предложите что-нибудь проще и короче, то я возьму все свои слова обратно.
2. В ORM вы определяете структуру данных и отношения ОДИН РАЗ, и не задумываетесь при выборке данных. В SQL же вы в каждом запросе цепляете абсолютно глупый компот из JOIN и заново указываете связи (несмотря на то, что структура уже определена DDL).
3. Hibernate-реализация не зависит от движка БД. Чтобы перейти на новый движок вам не нужно будет перелопачивать тонны кода, достаточно поменять пару строчек в конфигурации. Более того, к Hibernate можно прикрутить сторонние движки, например Lucene.
4. Hibernate позволяет в простой форме реализовать наследование.
5. Кеш данных, кеш второго уровня и прочие вкусности.
6. При переименовании таблиц/полей не придется апдейтить все запросы (количество которых может быть вырасти до тысяч), а достаточно лишь поменять меппинг.
А теперь самое главное:
bus.getDrivers() намного проще, чем
SELECT * FROM drivers, busdriver WHERE drivers.driver_id = busdriver.driver_id AND bus_id = xxx
В добавок, в IDEs типа Eclipse при вводе "bus." вылезет полный список полей объекта. В SQL же запросах постоянно придется консультировать правильное написание полей в структуре данных.
Как это ни странно, Hibernate плохо приспособлен для функционирования в среде веб, особенно если вы не пользуетесь EJB контейнером. Проблема в том, что связанные поля и коллекции с lazy fetching не могут использоваться за пределами сессии. Например если в примере автора поле Bus.drivers замепить как lazy, то
BusDAO.getBusById( ... ).getDrivers().get( ... )
не выдаст водителя автобуса, поскольку обращение к полю drivers (и фетчинг коллекции) лежит за пределами сессии. Это происходит всегда, когда вы используете, например, любой mvc фреймворк. В этом случае фетчинг lazy полей может происходить не только в action, но и в момент рендеринга страницы.
Как возможное решение можно написать фильтр для Tomcat, который до обработки запроса открывает новую hibernate-сессию и записывает ее как атрибут в объект request, а после обработки делает commit и закрывает ее.