Спасибо за подсказку, я незнаком с nginx. Слышал, что nginx более производителен в сравнении с Apache. На личном опыте скажу, что и Apache очень шустр. У нас когда-то при переходе на кластер, Apache поставили на тот же сервер, что и один из узлов. Каких-то проблем с производительностью замечено не было, несмотря на то, что в обычном режиме работы JBoss-а на этом сервере, он забирает 80-95% процессорного времени. Думаю, что до тех пор, пока количество запросов в сутки не перевалило семизначные цифры, можно не беспокоиться о производительности Apache.
Ну, закрытие HTTP/HTTPS скорее подсказка необычного решения, а не руководство к действию — кому-то интересно, кому-то нет. Да, вы правы, с доступом внутренних пользователей возникнут проблемы, особенно если они хотят посмотреть что происходит на конкретном сервере приложений, а не абстрактном, выбранном балансировщиком. С другой стороны, например, наши админы редко пользуются той же jmx-консолью, так что лично я серьезно подумываю о том, чтобы таки закрыть коннекторы.
Насчет деплоя — зависит от вашей бизнес-логики. У меня есть система, в которой данное решение дало возможность выполнять «на горячую» любые действия (обновление, изменение конфигурации) с перезапуском JBoss-а, при этом оставаясь онлайн. Останавливается один узел, Apache это видит, перенаправляет запросы на другой узел, все прозрачно для внешних клиентов. При обновлении, после запуска ранее остановленного узла, он включается в кластер, НО важный момент — в этот период времени на разных узлах запросы обрабатывает разная версия вашего ПО. После обновления и перезапуска второго узла, версии соответственно уравниваются. Это пример для режима standalone, именно поэтому я его использую. Насколько я понял, режим domain использует совсем другие принципы, там обновлением управляет главный узел, а не человек. Для нас такой подход к версионности промышленного ПО приемлем, для кого-то — нет. Система обрабатывает не связанные между собой запросы к веб-сервисам, поэтому после восстановления работоспособности обоих узлов нагрузка сразу равномерно распределяется по мере поступления новых запросов.
С «приклеенными» сессиями такого не будет: если посреди рабочего дня перезапустить один узел, все пользователи приклеятся к другому, и останутся там пока не выйдут из системы, перезапущенный будет простаивать. Что делать с этим во второй нашей системе я еще не думал, скорее всего, такого вольного обращения с серверами приложений в этом случае уже не получится.
Согласен. У нас Система прекрасно работала под управлением JBoss 5.1. Запланировали переход на семерку, вроде как развитие системы. Оказалось, что все самые нужные нам возможности 5-ки отсутствуют в 7-ке, пришлось искать и применять сторонние технологии. Практически всё делается по-другому. Убил массу времени, перерыл кучу форумов, переписал массу кода (коммит размером 1000 файлов, измененных только ради сохранения текущей функциональности). На переход убит месяц времени, затронуты абсолютно все модули системы.
Я уже думал, что все зря, столько мучений только ради новой циферки в версии сервера приложений. То, что 7-ка стартует быстрее — пыль, промышленные сервера не перезапускают каждые 5 минут, кому нужен быстрый старт (к тому же, только пустой сервер стартует быстро, после развертывания нашего приложения время старта с 3-х секунд увеличилось до 40-ка). Не грузит в память сразу лишние классы — сколько памяти мы на этом сэкономили, 1 мегабайт, 2? В общем, поначалу сильно разочаровался. Но сделал нагрузочное тестирование, и оказалось, что производительность работы веб-сервисов повысилась на 20-30%, а это ох как немало (система обрабатывает сотни тысяч запросов посредством веб-сервисов в сутки). И это лишь то, что явно бросилось в глаза, может еще где-то что-то получше работает.
Не могу плюсануть, поэтому напишу. Такая же ситуация, сервис Гугла «знает» мой телефон, но найти не смог. В сервисе скомандовал позвонить, звонок дошел через минуту. После этого вернулся на сервис, и увидел себя на карте. В телефоне уже давно указал свой гугловый логин, по ним же вошел на сервис по ссылке в статье.
ОК, у нас разные взгляды на понятие Хобби, и мы оба по-своему правы. Мне кажется так:
— Вы склонны считать хобби любое занятие, "которым регулярно занимаются на досуге, для души".
— Я отношусь к хобби как к интересному занятию, требующему при этом некоей самоотдачи и достижений.
Оба мнения верны, и находят подтверждение в той же Википедии. Ну, а если применить ваше видение, то у меня (да и у большинства людей) тоже много разных хобби.
Оффтоп с подковыркой: алкоголизм — это хобби? Я вот, например, неравнодушен к спиртному, и свое время регулярно занимался этим на досуге, для души. А вот теперь стараюсь себя ограничивать, что-то вроде борьбы с хобби… А кроме шуток, даже если не брать в расчет такие пагубные регулярные занятия, как, например, игромания, бывает же что хобби идет и во вред… Да даже мои сайты, они отбирают часы моего отдыха, ведь несмотря на то, что занятие мне нравится, я не отдыхаю занимаясь им…
В общем и целом понятно, но я считаю, что немалая часть «притянута за уши», и хобби не является. Вот выдержка из определения хобби в Википедии:
Основная цель хобби — помочь самореализоваться. Хобби со временем может вырасти в основную деятельность, которая приносит деньги
Далее идет категоризация видов хобби, ваши не подпадают ни под один пункт. Понятно, что там далеко не все, но просто пробежавшись можно сориентироваться какой тип занятости представляет собой хобби. Конкретно по вашим пунктам:
1. В игры играют все и просто увлечение играми — это не хобби, а времяпровождение. Если бы Вы участвовали в серьезных турнирах по Контре, то да — это уже что-то большее, это уже тянет на хобби.
2. Просто чтение иногда, чтобы расслабиться — опять же, не хобби. Если бы вы поставили себе задачу, например, собрать сочинения всех фантастов с мировым именем в свою коллекцию, особенно увлекаясь поиском редких изданий, тогда другой разговор. Единственный пункт, для которого есть что-то немного схожее в Википедии, но явно другой уровень: "букинистика — торговля старой книгой и другими печатными антикварными изданиями"
3. Сериалы: тут вообще говорить не о чем — это просто отдых, все смотрят телевизор, при чем тут хобби?
4, 5. Это не хобби, это работа. Не бывает в природе не саморазвивающихся программистов (если и есть исключения, они лишь подтверждают правило). Тот, факт, что кроме основной деятельности (я тоже, кстати, Java-программист), вы изучаете администрирование, предполагает что вы хороший специалист, но хобби тут ни при чем. К тому же, если бы необходимость по работе не возникала, стали бы вы этим заниматься (положа руку на сердце)?
6. Называть семью хобби, как-то вообще не комильфо, уж извините.
Мне кажется, что вы просто разносторонний человек, и скорее всего, профессионал своего дела. Но вот хобби я у вас не вижу ("занимался" — в прошедшем времени, не так ли?)…
Несогласие чем-то обосновано? Лично у меня, например, есть любимая работа, семья (жена и ребенок), и одно хобби — сайтостроение. У меня есть один так называемый Сайт Для Людей (СДЛ, терминология SEO-шников) и много т.н. говносайтов (сайты для поисковых машин). Несмотря на то, что ребенком я почти не занимаюсь, на одно хобби времени не хватает. Мне повезло, что я быстро и качественно справляюсь с основной работой, и поэтому могу уделить часть рабочего, а также обеденного времени своему хобби (конечно, в добавок к вечерам и выходным дням, по возможности). И даже несмотря на это, мне явно не хватает времени, динамика развития сайтов нестабильная и ниже, чем мне хотелось бы.
Понятно, что если ваше хобби — это покер с друзьями в вечер пятницы и лыжи в субботу, то можно и еще пару-тройку хобби завести. А если нечто более серьезное? Автор статьи, насколько я понял, даже основную работу забросил из-за хобби. Бывают хобби исключительно для развлечения и приятного времяпрепровождения, а бывает нечто большее — обычно это какие-то личные проекты, или даже стартапы, которые от обычной основной работы могут отличаться в основном высоким интересом к делу их автора и реализатора. Т.е., термин «хобби» к таким вещам подходит лишь потому, что человеку это нравится, несмотря на то, что это уже скорее работа, чем увлечение…
Похожая ситуация. У нас пропускная система, у каждого личная карточка, время входа/выхода фиксируется в электронном журнале. Когда кадровикам заняться нечем, они просматривают отчет и заставляют опоздавших писать объяснительные, эдакие неожиданные облавы раз в два месяца. Только вот за опоздание принимаются 5-20 минут, а позже уже в выборку не попадает, так что если опаздывать — так минимум на час.
Вообще, всевозможные методы контроля в большинстве случаев дают эффект обратный ожидаемому. Руководство смотрит на эти методы через какую-то особую призму, либо розовые очки. Несмотря на то, что сами руководители были зачастую не так давно рядовыми сотрудниками, они умудряются быстро забыть, какую реакцию вызывают у них их нововведения. Тот же контроль за опоздавшими: все сотрудники компании с утра-пораньше, еще не добравшись до работы уже получают психологическую нагрузку в виде постоянно крутящейся в подсознании мысли — только бы не опоздать! Ботинки не чищены? Дождь пошел, надо достать куртку? Пробка? Дорога каждая секунда! Я каждый день вижу, как ускоряют шаг все наши сотрудники при приближении к дверям офиса, и сам чувствую этот утренний груз на плечах. Скорее бы ткнуть карточкой на пропускном пункте и расслабиться. Вопрос в том, а стоило ли каждый будний день так психологически напрягать каждого сотрудника? Что дороже, лишние 10 минут (не всех, а только опоздавших), проведенные в офисе или хорошее настроение сотрудника? Неужели такая овчинка выделки стоит?
В большинстве случаев руководство думает только о измеримых показателях, а о психологической составляющей никто и не вспомнит. Как часто при внедрении очередной методики контроля участвует психолог? В большинстве компаний нет такой должности и никто не приглашает их при продумывании внутренних процессов. Да ладно психолог, попытались бы хоть поставить себя на место подопытного сотрудника, прежде чем обрушивать на его голову очередной рецепт повышения трудоспособности…
надо включать профилятор и совершенно по месту смотреть
Не, ну человек пишет же, что "периодически приходится пользоваться профайлером", наверняка не просто так. А раз уж и написать об этом решил, то видимо и профит заметный был.
Хотя, лично у меня, если честно, первой реакцией на статью было съязвить что-нибудь. Но, подумал и передумал. Хотя интересного в статье мало, а большая часть материала — просто здравый смысл и будни программиста, но все же это напоминание о том, что не следует забывать про оптимизацию, и самый простой и будничный кусок кода может с аппетитом откушать процессора. Лишь бы оптимизация не была преждевременной. А то я вот, например, не так давно увидел в старом, но добротном коде веб-сервиса блок synchronized и решил заменить его на что-нибудь более продвинутое из того, что появилось в Java 5/6. НО! Перед тем как сделать это, сделал замеры производительности. Оказалось, что работа в этом блоке длится 0.001% (одна тысячная процента) от общего времени вызова метода веб-сервиса. «Не все то золото, что блестит» — подумал я, и оставил все как есть.
А вот и нет. Если ссылки каким-то образом уходят в публичный доступ, то почему это не может произойти за считанные минуты/часы? А Гугл индексирует многие сайты также в считанные минуты. Вуаля — через часок после отправки письма мы можем найти в Гугле нужные нам ссылки. Когда я спрашивал "А какой именно срок?", я далее пытался сказать, что нет ответа на этот вопрос. Если ссылки были в личной почте пользователя, то ответственность за их конфиденциальность лежит лично на самом пользователе, и никакие ограничения по количеству использований и срокам ничего не дадут.
Не решит проблему, если сам пользователь ни разу не воспользовался этой ссылкой, а после она попала в открытый доступ. Ограничить срок действия? А какой именно срок? День, два? А если я в отпуске был, а спустя месяц почту разгребаю?
убрать все ссылки из индекса Google
Никто ничего не может убрать из индекса Google. Их робот сам решит убрать или нет, и если да, то когда именно это сделать. Можно лишь убрать страницы на своем сайте, на которые ведут эти ссылки, и когда-нибудь, когда Гугл решит, что они удалены достаточно давно, то может и удалит из индекса.
регистрация без подтверждения
А это вообще свинство какое-то
Дыр в безопасности, судя по всему у Баду хватает, но, с другой стороны — на кой черт пользователь публикует в открытый доступ свои ссылки? Хотя, с учетом того, что средний пользователь соц. сетей технически малограмотен, в письмах со ссылками надо крупным текстом писать что нельзя передавать их третьей стороне. Многие системы предупреждают, неужто в письмах Баду нет такого? А если есть, то извините, никто не может защитить пользователя от самого себя…
Плюсанул бы, да правов нету… Буквально месяц назад такая же мысль возникла после внедрения в конторе обязательной для всех отчетности: ежедневно надо вбить в систему 8 часов выполненных задач. Я и подумал: раньше надо было уметь выполнять задачи, теперь надо уметь заполнять задачи. И ведь это не одно и то же, я реально стал меньше работать после внедрения такой системы, сижу вон Хабр комментирую…
Ого, у вас жизненный путь однако! Не хотите написать пост об этом?
Да уж, кому ни говорю об этом, все удивляются, наверное стоит когда-то написать…
такую бюрократию видел только на государственных предприятиях
Полностью согласен, на них склонность к бумагомаранию гораздо выше. В коммерческих конторах, начиная со среднего размера тоже появляется бюрократия, но там обычно пытаются сделать с умом и пользы от от нее больше, чем вреда. А вот гос. сектор зазеркалье какое-то, такое впечатление что любыми способами делают все возможное для снижения производительности и удовлетворенности от работы. Как в анекдоте про армию: мне не надо чтобы быстрее, мне надо чтобы задолбался…
2 ИТРа на одного работника
Думаю, такая ситуация на противоположных концах организации труда на пром. предприятиях: с одной стороны такие вот умирающие заводы, с другой стороны высокотехнологичные производства, где множество выполняемых задач автоматизированы/роботизированы.
Нет, конечно в затронутой теме смысл есть, но не в таких масштабах. Я, кстати, последние два года работаю в отделе, занимающемся разработкой и поддержкой двух критичных гос. систем, и у нас соотношение сотрудников один-к-одному:
1 Начальник
1 Аналитик/Делопроизводитель
1 Разработчик/Архитектор
1 Админ/Консультант (поддержка пользователей)
И, что интересно, при наличии очень разнообразных задач разработки (от правки багов до смены технологий и бизнес-процессов), при таком соотношении сотрудников всё как-то тихо-мирно. Более того, начальник на работе задерживается практически каждый день, а я, разработчик, работаю всегда строго 40 часов в неделю.
Так подумать, может в каких-то случаях и правда начальников побольше нужно, а то они, бедняги, как-то не справляются…
У меня трудовой стаж лет 17 наверное, я трудился в разных организациях на таких должностях, как каменщик, завскладом, бухгалтер-оператор, программист, но такого уровня бюрократии, о котором Вы спрашиваете не встречал нигде. Всем понятно, что анекдоты и смешные истории многое утрируют, поэтому надеюсь, что Ваш вопрос несерьезен.
Если у вас есть статистика по продажам подобных книг, и она вас удовлетворяет, то однозначно выпускайте. Тема хорошая, и, несмотря на заявления о том, что кому надо прочитает в оригинале (те, кто так заявляют, говорят о не более 1% людей из категории заинтересованных в этой теме лиц), достаточно долгоиграющая. В оригинале прочитают единицы, да и то большая их часть осилит далеко не всю книгу. Отличная настольная книга, которая должна быть в любом отделе Java-разработки. Естественно, далеко не все из тех, кто ее купит, прочитает ее целиком даже на русском, а уж за оригинал тем более и говорить нечего. Кроме несомненной пользы для начинающих JEE-разработчиков (must have), ещё пригодится как справочник или полистать в свободно-ленивое время.
Лично у меня опыт 10 лет в JEE и когда-то во время командировки в Москву искал именно такую книгу, но так и не нашел. Купил похожую, но с уклоном в IBM-ские технологии и еще кучу книг по Java. Ни одну из купленных книг так и не прочитал целиком, НО — купил ведь, а вас, как издательство должна интересовать именно покупка, не так ли? Хотя последние 5-7 лет я не читаю книг вообще (я бы с удовольствием, но не получается), но если попадется на глаза эта книга, то куплю и даже пролистаю и что-то прочитаю. Потом отнесу на работу, полистать другим.
Мне кажется, что разница между архитектурой и дизайном есть только в случае если у вас есть и архитекторы и дизайнеры. В описанных мной случаях была система и был один ответственный за архитектуру/дизайн/идеологию, как это не назови.
Насчет тестов: чтобы купить что-нибудь хорошее, надо сначала продать что-нибудь хорошее. На проекте были определенные ресурсы, если бы их затратили на написание тестов, то проект не был бы сдан в срок. К тому же, я уже сказал про качество кода, уверен, что тесты были бы еще хуже.
И, кстати, в первом случае тестов тоже не было (вообще в проекте, а не конкретно в подсистеме). И не только в этом проекте, а вообще во всех проектах компании. Как-то пробовали «на вкус», но так и не прижилось. Мое личное мнение — наличие тестов занимает далеко не самую важную роль в успешности проекта.
Случай 1, успешный. Участвовал в разработке некоего портала, большая часть функций которого была знакома нашим разработчикам — вбивалка данных, то, что мы клепали и в других Системах. В команде я был на роли разработчика, одного из 6-10 (в разные моменты процесса развития Системы). Но потребовалась новая подсистема, идеология которой шла вразрез опыту любого человека в компании (не только разработчиков, но и аналитиков, менеджеров и т.д.). Никто не хотел браться, т.к. не знали с какой стороны вообще подойти, а время шло. Была еще проблема со сроками, начав с нуля через пару месяцев надо было показать работающий продукт. В общем я решился войти архитектором в подсистему, хотя так же, как и остальные понятия не имел от чего плясать. Начал анализировать как требования Заказчика могут выглядеть после реализации, пытаться рисовать структуру БД, прикидывать структуру кода и т.д. Потихоньку-помаленьку (но укладываясь в сроки) подсистема начала вырисовываться, в конце-концов абсолютно непонятный функционал удалось уложить в привычные всем считал/изменил/сохранил. Подсистема оказалась, на мой взгляд, самым успешным проектом подразделения за многие годы, причем не только в части качественной разработки, но и по удовлетворенности клиента, соблюдению сроков, закрытию контрактов. Так вот, будучи на роли архитектора, я постоянно программировал. Первые строчки кода и основная структура БД были целиком моими, остальные стали подключаться позже. Постепенно я кодил все меньше, и в конце-концов, когда все было поставлено на поток, вышел из команды проекта, еще до окончательной сдачи подсистемы. Где-то читал, что только реализация может раскрыть все недочеты проектирования, и этот случай подтверждает это на 100%.
Случай 2, провальный. Архитектор в нашей компании спроектировал систему в общем, выдав это в виде документа. А непосредственно кодинг отдал младшему разработчику. И вроде архитектуру кода контролировал, и как-то присматривал за разработчиком, но сам если и кодил, то только интерфейсы. Систему в конце концов сдали в промышленную эксплуатацию, и она работает долгие годы. Можно сказать, что «где же тут провал»? Система работает, деньги за нее получены, а что там внутри — дело десятое. Мне довелось спустя годы попасть на дальнейшее развитие и поддержку этой системы, и то, с чем я там столкнулся, повергло меня в шок. Я никогда в жизни не видел более страшного кода, а его поддержка — пытка. Любое сколь-нибудь серьезное изменение в большинстве случаев тянет за собой также и хороший рефакторинг, причем большая часть времени занимает именно рефакторинг, а не требующаяся доработка. Провал — поддержка кривого кода требует гораздо больше времени, и, соответственно денег. И конечно же, очень часто даже небольшие изменения несут побочные эффекты в виде ошибок в совершенно неожиданных местах. Провал — неудовлетворенность конечного пользователя, дополнительное время (и деньги) на тестирование, поиск и исправление ошибок, повторные сборки и передачи обновлений. Я думаю, что если бы архитектор непосредственно участвовал в реализации, хотя бы на начальных этапах, и программировал сам, то все было бы по-другому.
Спасибо, слышал. Но не вижу никакого смысла его применения конкретно в нашем проекте. Еще раз повторю — пользователю загружается 3МБ JavaScript раз в месяц, это немного даже для возможностей сетей десятилетней давности. Специально спросил сейчас у специалиста поддержки, он сказал что пользователи не жалуются на то, что после обновления первый вход в систему длится дольше. А заниматься преждевременной оптимизацией — плохая практика.
Насчет деплоя — зависит от вашей бизнес-логики. У меня есть система, в которой данное решение дало возможность выполнять «на горячую» любые действия (обновление, изменение конфигурации) с перезапуском JBoss-а, при этом оставаясь онлайн. Останавливается один узел, Apache это видит, перенаправляет запросы на другой узел, все прозрачно для внешних клиентов. При обновлении, после запуска ранее остановленного узла, он включается в кластер, НО важный момент — в этот период времени на разных узлах запросы обрабатывает разная версия вашего ПО. После обновления и перезапуска второго узла, версии соответственно уравниваются. Это пример для режима standalone, именно поэтому я его использую. Насколько я понял, режим domain использует совсем другие принципы, там обновлением управляет главный узел, а не человек. Для нас такой подход к версионности промышленного ПО приемлем, для кого-то — нет. Система обрабатывает не связанные между собой запросы к веб-сервисам, поэтому после восстановления работоспособности обоих узлов нагрузка сразу равномерно распределяется по мере поступления новых запросов.
С «приклеенными» сессиями такого не будет: если посреди рабочего дня перезапустить один узел, все пользователи приклеятся к другому, и останутся там пока не выйдут из системы, перезапущенный будет простаивать. Что делать с этим во второй нашей системе я еще не думал, скорее всего, такого вольного обращения с серверами приложений в этом случае уже не получится.
Я уже думал, что все зря, столько мучений только ради новой циферки в версии сервера приложений. То, что 7-ка стартует быстрее — пыль, промышленные сервера не перезапускают каждые 5 минут, кому нужен быстрый старт (к тому же, только пустой сервер стартует быстро, после развертывания нашего приложения время старта с 3-х секунд увеличилось до 40-ка). Не грузит в память сразу лишние классы — сколько памяти мы на этом сэкономили, 1 мегабайт, 2? В общем, поначалу сильно разочаровался. Но сделал нагрузочное тестирование, и оказалось, что производительность работы веб-сервисов повысилась на 20-30%, а это ох как немало (система обрабатывает сотни тысяч запросов посредством веб-сервисов в сутки). И это лишь то, что явно бросилось в глаза, может еще где-то что-то получше работает.
— Вы склонны считать хобби любое занятие, "которым регулярно занимаются на досуге, для души".
— Я отношусь к хобби как к интересному занятию, требующему при этом некоей самоотдачи и достижений.
Оба мнения верны, и находят подтверждение в той же Википедии. Ну, а если применить ваше видение, то у меня (да и у большинства людей) тоже много разных хобби.
Оффтоп с подковыркой: алкоголизм — это хобби? Я вот, например, неравнодушен к спиртному, и свое время регулярно занимался этим на досуге, для души. А вот теперь стараюсь себя ограничивать, что-то вроде борьбы с хобби… А кроме шуток, даже если не брать в расчет такие пагубные регулярные занятия, как, например, игромания, бывает же что хобби идет и во вред… Да даже мои сайты, они отбирают часы моего отдыха, ведь несмотря на то, что занятие мне нравится, я не отдыхаю занимаясь им…
Далее идет категоризация видов хобби, ваши не подпадают ни под один пункт. Понятно, что там далеко не все, но просто пробежавшись можно сориентироваться какой тип занятости представляет собой хобби. Конкретно по вашим пунктам:
1. В игры играют все и просто увлечение играми — это не хобби, а времяпровождение. Если бы Вы участвовали в серьезных турнирах по Контре, то да — это уже что-то большее, это уже тянет на хобби.
2. Просто чтение иногда, чтобы расслабиться — опять же, не хобби. Если бы вы поставили себе задачу, например, собрать сочинения всех фантастов с мировым именем в свою коллекцию, особенно увлекаясь поиском редких изданий, тогда другой разговор. Единственный пункт, для которого есть что-то немного схожее в Википедии, но явно другой уровень: "букинистика — торговля старой книгой и другими печатными антикварными изданиями"
3. Сериалы: тут вообще говорить не о чем — это просто отдых, все смотрят телевизор, при чем тут хобби?
4, 5. Это не хобби, это работа. Не бывает в природе не саморазвивающихся программистов (если и есть исключения, они лишь подтверждают правило). Тот, факт, что кроме основной деятельности (я тоже, кстати, Java-программист), вы изучаете администрирование, предполагает что вы хороший специалист, но хобби тут ни при чем. К тому же, если бы необходимость по работе не возникала, стали бы вы этим заниматься (положа руку на сердце)?
6. Называть семью хобби, как-то вообще не комильфо, уж извините.
Мне кажется, что вы просто разносторонний человек, и скорее всего, профессионал своего дела. Но вот хобби я у вас не вижу ("занимался" — в прошедшем времени, не так ли?)…
Понятно, что если ваше хобби — это покер с друзьями в вечер пятницы и лыжи в субботу, то можно и еще пару-тройку хобби завести. А если нечто более серьезное? Автор статьи, насколько я понял, даже основную работу забросил из-за хобби. Бывают хобби исключительно для развлечения и приятного времяпрепровождения, а бывает нечто большее — обычно это какие-то личные проекты, или даже стартапы, которые от обычной основной работы могут отличаться в основном высоким интересом к делу их автора и реализатора. Т.е., термин «хобби» к таким вещам подходит лишь потому, что человеку это нравится, несмотря на то, что это уже скорее работа, чем увлечение…
Вообще, всевозможные методы контроля в большинстве случаев дают эффект обратный ожидаемому. Руководство смотрит на эти методы через какую-то особую призму, либо розовые очки. Несмотря на то, что сами руководители были зачастую не так давно рядовыми сотрудниками, они умудряются быстро забыть, какую реакцию вызывают у них их нововведения. Тот же контроль за опоздавшими: все сотрудники компании с утра-пораньше, еще не добравшись до работы уже получают психологическую нагрузку в виде постоянно крутящейся в подсознании мысли — только бы не опоздать! Ботинки не чищены? Дождь пошел, надо достать куртку? Пробка? Дорога каждая секунда! Я каждый день вижу, как ускоряют шаг все наши сотрудники при приближении к дверям офиса, и сам чувствую этот утренний груз на плечах. Скорее бы ткнуть карточкой на пропускном пункте и расслабиться. Вопрос в том, а стоило ли каждый будний день так психологически напрягать каждого сотрудника? Что дороже, лишние 10 минут (не всех, а только опоздавших), проведенные в офисе или хорошее настроение сотрудника? Неужели такая овчинка выделки стоит?
В большинстве случаев руководство думает только о измеримых показателях, а о психологической составляющей никто и не вспомнит. Как часто при внедрении очередной методики контроля участвует психолог? В большинстве компаний нет такой должности и никто не приглашает их при продумывании внутренних процессов. Да ладно психолог, попытались бы хоть поставить себя на место
подопытногосотрудника, прежде чем обрушивать на его голову очередной рецепт повышения трудоспособности…Хотя, лично у меня, если честно, первой реакцией на статью было съязвить что-нибудь. Но, подумал и передумал. Хотя интересного в статье мало, а большая часть материала — просто здравый смысл и будни программиста, но все же это напоминание о том, что не следует забывать про оптимизацию, и самый простой и будничный кусок кода может с аппетитом откушать процессора. Лишь бы оптимизация не была преждевременной. А то я вот, например, не так давно увидел в старом, но добротном коде веб-сервиса блок synchronized и решил заменить его на что-нибудь более продвинутое из того, что появилось в Java 5/6. НО! Перед тем как сделать это, сделал замеры производительности. Оказалось, что работа в этом блоке длится 0.001% (одна тысячная процента) от общего времени вызова метода веб-сервиса. «Не все то золото, что блестит» — подумал я, и оставил все как есть.
Никто ничего не может убрать из индекса Google. Их робот сам решит убрать или нет, и если да, то когда именно это сделать. Можно лишь убрать страницы на своем сайте, на которые ведут эти ссылки, и когда-нибудь, когда Гугл решит, что они удалены достаточно давно, то может и удалит из индекса.
А это вообще свинство какое-то
Дыр в безопасности, судя по всему у Баду хватает, но, с другой стороны — на кой черт пользователь публикует в открытый доступ свои ссылки? Хотя, с учетом того, что средний пользователь соц. сетей технически малограмотен, в письмах со ссылками надо крупным текстом писать что нельзя передавать их третьей стороне. Многие системы предупреждают, неужто в письмах Баду нет такого? А если есть, то извините, никто не может защитить пользователя от самого себя…
Да уж, кому ни говорю об этом, все удивляются, наверное стоит когда-то написать…
Полностью согласен, на них склонность к бумагомаранию гораздо выше. В коммерческих конторах, начиная со среднего размера тоже появляется бюрократия, но там обычно пытаются сделать с умом и пользы от от нее больше, чем вреда. А вот гос. сектор зазеркалье какое-то, такое впечатление что любыми способами делают все возможное для снижения производительности и удовлетворенности от работы. Как в анекдоте про армию: мне не надо чтобы быстрее, мне надо чтобы задолбался…
Думаю, такая ситуация на противоположных концах организации труда на пром. предприятиях: с одной стороны такие вот умирающие заводы, с другой стороны высокотехнологичные производства, где множество выполняемых задач автоматизированы/роботизированы.
1 Начальник
1 Аналитик/Делопроизводитель
1 Разработчик/Архитектор
1 Админ/Консультант (поддержка пользователей)
И, что интересно, при наличии очень разнообразных задач разработки (от правки багов до смены технологий и бизнес-процессов), при таком соотношении сотрудников всё как-то тихо-мирно. Более того, начальник на работе задерживается практически каждый день, а я, разработчик, работаю всегда строго 40 часов в неделю.
Так подумать, может в каких-то случаях и правда начальников побольше нужно, а то они, бедняги, как-то не справляются…
— С бригадиром — 10.
— А без бригадира?
— А без бригадира вообще никто не работает.
PS. До того как проработать программистом 10 лет, я 4 года работал строителем, это один из моих любимых анекдотов тех времен…
Лично у меня опыт 10 лет в JEE и когда-то во время командировки в Москву искал именно такую книгу, но так и не нашел. Купил похожую, но с уклоном в IBM-ские технологии и еще кучу книг по Java. Ни одну из купленных книг так и не прочитал целиком, НО — купил ведь, а вас, как издательство должна интересовать именно покупка, не так ли? Хотя последние 5-7 лет я не читаю книг вообще (я бы с удовольствием, но не получается), но если попадется на глаза эта книга, то куплю и даже пролистаю и что-то прочитаю. Потом отнесу на работу, полистать другим.
Насчет тестов: чтобы купить что-нибудь хорошее, надо сначала продать что-нибудь хорошее. На проекте были определенные ресурсы, если бы их затратили на написание тестов, то проект не был бы сдан в срок. К тому же, я уже сказал про качество кода, уверен, что тесты были бы еще хуже.
И, кстати, в первом случае тестов тоже не было (вообще в проекте, а не конкретно в подсистеме). И не только в этом проекте, а вообще во всех проектах компании. Как-то пробовали «на вкус», но так и не прижилось. Мое личное мнение — наличие тестов занимает далеко не самую важную роль в успешности проекта.
Случай 1, успешный. Участвовал в разработке некоего портала, большая часть функций которого была знакома нашим разработчикам — вбивалка данных, то, что мы клепали и в других Системах. В команде я был на роли разработчика, одного из 6-10 (в разные моменты процесса развития Системы). Но потребовалась новая подсистема, идеология которой шла вразрез опыту любого человека в компании (не только разработчиков, но и аналитиков, менеджеров и т.д.). Никто не хотел браться, т.к. не знали с какой стороны вообще подойти, а время шло. Была еще проблема со сроками, начав с нуля через пару месяцев надо было показать работающий продукт. В общем я решился войти архитектором в подсистему, хотя так же, как и остальные понятия не имел от чего плясать. Начал анализировать как требования Заказчика могут выглядеть после реализации, пытаться рисовать структуру БД, прикидывать структуру кода и т.д. Потихоньку-помаленьку (но укладываясь в сроки) подсистема начала вырисовываться, в конце-концов абсолютно непонятный функционал удалось уложить в привычные всем считал/изменил/сохранил. Подсистема оказалась, на мой взгляд, самым успешным проектом подразделения за многие годы, причем не только в части качественной разработки, но и по удовлетворенности клиента, соблюдению сроков, закрытию контрактов. Так вот, будучи на роли архитектора, я постоянно программировал. Первые строчки кода и основная структура БД были целиком моими, остальные стали подключаться позже. Постепенно я кодил все меньше, и в конце-концов, когда все было поставлено на поток, вышел из команды проекта, еще до окончательной сдачи подсистемы. Где-то читал, что только реализация может раскрыть все недочеты проектирования, и этот случай подтверждает это на 100%.
Случай 2, провальный. Архитектор в нашей компании спроектировал систему в общем, выдав это в виде документа. А непосредственно кодинг отдал младшему разработчику. И вроде архитектуру кода контролировал, и как-то присматривал за разработчиком, но сам если и кодил, то только интерфейсы. Систему в конце концов сдали в промышленную эксплуатацию, и она работает долгие годы. Можно сказать, что «где же тут провал»? Система работает, деньги за нее получены, а что там внутри — дело десятое. Мне довелось спустя годы попасть на дальнейшее развитие и поддержку этой системы, и то, с чем я там столкнулся, повергло меня в шок. Я никогда в жизни не видел более страшного кода, а его поддержка — пытка. Любое сколь-нибудь серьезное изменение в большинстве случаев тянет за собой также и хороший рефакторинг, причем большая часть времени занимает именно рефакторинг, а не требующаяся доработка. Провал — поддержка кривого кода требует гораздо больше времени, и, соответственно денег. И конечно же, очень часто даже небольшие изменения несут побочные эффекты в виде ошибок в совершенно неожиданных местах. Провал — неудовлетворенность конечного пользователя, дополнительное время (и деньги) на тестирование, поиск и исправление ошибок, повторные сборки и передачи обновлений. Я думаю, что если бы архитектор непосредственно участвовал в реализации, хотя бы на начальных этапах, и программировал сам, то все было бы по-другому.