Наша небольшая, но амбициозная команда остро нуждается в пополнении.
Мы - это технологический стартап ENTARENA, Inc. со штаб-квартирой в Palo Alto, CA. Сейчас мы открываем офис в Москве, в который нам нужны:
- разработчик на Clojure: http://moikrug.ru/vacancies/637933049/
- Flash-разработчик: http://moikrug.ru/vacancies/465636423/
- UI-дизайнер (опять-таки с уклоном в Flash): http://moikrug.ru/vacancies/250512560/
Пишите, рекомендуйте знакомым, и т.п.
http://squadette.livejournal.com/599819.html
непрограммистам лучше даже не заглядывать, травмирует психику.
Haskell - крайне интересное явление в чисто гуманитарном смысле.
что-то подобное неизбежно должно было появиться в нашей богоспасаемой индустрии, как естественный протест против превращения программирования в инженерную дисциплину.
вещь со всех сторон полезная. циничные практики, прикидывая, как эти жуткие конструкции приспособить к своим жизнненным потребностям, узнают много нового, а сумма всех этих усилий в итоге двигает индустрию вперед.
[Cmd-Tab -> Safari]
почему все без исключения формальные процессы управления разработкой сосут big time, будучи применяемыми "в лоб"?
очевидно, потому что сама природа этой работы обладает слишком недетерминистским характером.
поясню.
допустим, мы имеем сложный технологический процесс, скажем - сборку автомобиля. совершенно независимо от того, какая смена стоит у станков и на конвейере, эта смена собирает одни и те же автомобили. они состоят из одинаковых деталей, сопряженных друг с другом идентичным образом. ну, с поправкой на брак и технологические допуски.
теперь возьмем какую-нибудь банальную задачу, ну я не знаю, веб-приложение электронного магазина. даже если задача имеет строжайшие спецификации, а окружение - принятые стандарты кодирования, эта задача, будучи порученной разным программистам, на выходе будет представлять собой две разные программы. если же программистам предоставить самостоятельный выбор инструментария... ну вы понимаете.
в программировании творчество - это ключевая составляющая любого по-настоящему удачного решения. программные продукты остаются качественными до тех пор, пока делающим эти продукты людям ИНТЕРЕСНО делать их лучше. и выигрывать в бизнесе будут те, кто в состоянии сделать программистам интересно, так сказать, in a long run.
поэтому все формальные процессы в нашей богоспасаемой индустрии нормально работают в лучшем случае на саппорте и сопровождении. попытка применять их в проектах, нацеленных на развитие (не говоря уже о новых продуктах), сродни применению заклинаний дождя. дождь может пойти, а может и не пойти, но было ли это результатом заклинания - никто никогда не узнает.
правильно же выстроенная разработка состоит из ведущих программистов, которые придумывают и делают продукт, подмастерьев, которые у них учатся, и оверхеда в виде менеджера, который бегает за кофе, обеспечивает апгрейд компьютеров, пиво и блядей. и зарплату получает меньше чем программисты. и конечно же (боже упаси!) ничем не руководит.
угадайте с одного раза компанию, в которой хорошо поняли этот принцип.
такие дела.
[Cmd-Tab -> Eclipse]
по рабочей надобности только что потребовалось перевести на русский термины dependency injection и inversion of control. поскольку сама концепция далеко не нова, а словосочетание IoC container в нашей богоспасаемой индустрии уже знают, наверное, даже программисты 1С, предполагалось, что существует какой-то устоявшийся термин, который легко может быть найден яндексом.
с первой попытки нашлись вот такие эээ варианты:
"инверсия зависимостей" (угадайте какой из двух терминов переведен? я так и не понял)
"обращение контроля" (fuck!)
"внедрение зависимости" (FUCK!!!)
и даже (drumroll) "инъекция зависимости"!!!!!
наиболее осторожные авторы оставляют в текстах английские варианты, и не рискуют их переводить.
даже не знаю, пытаться ли искать дальше, рабочий день рискует пойти прахом.
По итогам несколькочасовой разборки ВНЕЗАПНО выяснилось, что XML-парсер от MSIE 7-8 вылетает с неизвестной ошибкой, если скормить ему по HTTP файл в кодировке windows-1251. С корректно прописанным encoding и прочими причиндалами.
Блядское ебаное позорище, а не софтверная компания. Извенити.
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
Майкрософт, сдохни!
После примерно пяти лет использования от IntelliJ IDEA пришлось отказываться. Не знаю как коллегам из JetBrains это удалось, но этот (на уровне версий 4 и 5) прекрасно продуманный, производительный и удобный продукт к версии 8 превратился в невменяемое, тормозное и запутанное bloatware.
С требованиями к памяти как у Oracle JDeveloper (если не хуже).
С громоздкими и неудобными настройками, организация которых зачем-то полностью переделывается в каждой версии.
С саппортом, который, помнится, блокирующую переход на версию 7 проблему не мог решить месяца три, пока она путем каких-то странных танцев с бубном не решилась сама.
Ну и с прочими характерными для коммерческого инструментария прелестями.
Очень мне жалко средств для рефакторинга, удобных клавиатурных шорткатов и diff-ов прямо в экране редактирования. Но все это вместе уже не лезло ни в какие ворота. Потраченных денег, конечно, тоже жалко.
Смигрировался я в результате на Eclipse, не без труда, но вполне успешно. User experience тут попроще, но зато все понятно, единообразно и предсказуемо. Чего и вам желаю.
Кредитная экспансия, бесславный конец которой мы сейчас наблюдаем в реальном времени, довольно любопытным образом проявила себя в нашей богоспасаемой индустрии.
Все те 10+ лет, что я занимаюсь разработкой, меня разные люди в разных обстоятельствах неизменно пытались убеждать, что концепция "давайте слепим систему <...> на коленке руками программиста, позавчера узнавшего про существование инструментария, с которым ему придется работать" является "экономически оправданной". Казалось бы, так оно и есть: мы делаем нечто гипсокартонное и позволяющее запустить продажи, и прибыль от продаж реинвестируем в производственный цикл, постепенно доводя продукт до нормальной кондиции. В качестве вариации - собираем команду профессионалов за мегабабло и лепим востребованный рынком копипейст, потому что рынок же всегда растет, и место для всех найдется.
Свой внутренний протест против этой модели я, как человек самокритичный, списывал на излишнее эстетство и перфекционизм.
И только теперь стало окончательно понятно, что вышеописанный подход - просто одна из разновидностей той самой пирамидальной схемы, за которую самым шустрым теперь турма сидеть, а всем остальным - жрать вкусную гречку ближайшие 10 лет.
Именно этот подход порождает бессмысленные образования типа поисковых сервисов без единой оригинальной идеи, безумные системы автоматизации бизнеса, требующие на поддержку ресурсов, которыми можно еще пару аналогичных бизнесов запустить, и прочие прелести.
А самое смешное в том, что все адепты этой схемы, похоже, до сих пор не понимают, как они попали :)
Провел эксперимент - перетащил БД одного из проектов из MySQL в PostgreSQL и погонял наиболее тяжелые запросы. Аккуратное использование DESC-индексов, которые появились в версии 8.3, на запросах с обратной сортировкой и LIMIT-ом дает прирост производительности примерно на два порядка, местами даже почти на три.
Офигеть просто.
Один раз этот эффект я уже наблюдал, ребята в одной из консультируемых компаний попробовали использовать DESC-индексы по моему совету в аналогичной ситуации - эффект был такой же. Но когда своими руками - все равно производит впечатление.
Выкладываю презентацию доклада про архитектуру CMS TRAVEL.RU на YAPC::Russia 2008 "May Perl"
В воскресенье буду выступать на конференции YAPC::Russia "May Perl". Доклад будет про CMS, на которой последние 5 (кажется) лет живет TRAVEL.RU - история создания, особенности архитектуры, эволюция и все такое прочее.
