Описанной проблеме много лет. НАиболее красиво и замечательно ее описал Сирил Паркинсон «ОКОНЧАТЕЛЬНЫЙ СПИСОК, или Принципы отбора кадров».
Суть:
«Современные методы сводятся к проверке умственного уровня и психологической беседе. Недостаток вышеозначенной проверки в том, что победители не знают совершенно ничего.
Наблюдателям могут угодить лишь скрытные мелочные субъекты себе на уме, которые мало говорят и ничего не делают. При таком методе нередко из пятисот человек выбирают именно того, кто через несколько недель окажется абсолютно непригодным. Без всякого сомнения, этот метод хуже всех.
Какой же метод применять нам в будущем?… Но суть тут в том, что все заявления выбрасывают в корзину, а речь пойдет лишь о человеке, который заявления не подавал.
Нет никакой возможности выбрать одного из трехсот умелых людей, снабженных прекрасными характеристиками. Приходится признать, что система неверна изначально. Незачем привлекать такую массу народу. Но никто об этом не знает, и объявления составлены так, что они неизбежно приманят тысячи. Легче и выгодней было бы подумать сразу.
Если же подумать, увидишь, что идеальное объявление привлечет одного человека, и того именно, кто нужен. Начнем с предельного случая:
»Требуется акробат, который может пройти по проволоке на высоте 200 м над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет. Явиться лично в цирк «Дикий Кот» от 9 до 10".
Быть может, слог и не очень хорош, но цель ясна: нужно так уравновесить риском денежную выгоду, чтобы не явилось больше одного соискателя.
Если все написать как следует, придет только один соискатель и сможет сразу или почти сразу приступить к работе. А если не придет никто? Значит, надо написать иначе, в чем — то мы завысили требования. То же самое небольшое объявление предложим в измененном виде. "
Как-то проводили мозговой штурм по данным, их связям и тому, как всё это хранить. Пришли к таким выводам:
Ничего лучше id и ссылки на них для исключения дублирования не придумали.
Хранилище требует три основных типа данных:
— Документ, тип которого дополнительно определяется классом допумента
— Список из id, имеет атомарное добавление и опционально атомарное удаление
— Счётчик атомарно изменяемый целочисленный.
— Дополнительно не помешает Массив, аналогичен списку с произвольным типом.
Документ есть данные, относящиеся напрямую к объекту. Остальное хранится с помощью ссылки на списки.
От хранилища требуются крайне быстрые и эффективные операции класса «достать по ключу» и «записать по ключу».
Для сложных запросов нужна отдельная система индексов, хранимых в быстрой памяти. Индекс состоит из пар ключ-id упорядоченных по ключу. В некоторых случаях индекс позволяет избежать запросов к спискам.
Непротиворечивость и согласованное состояние гарантируется атомарностью (на уровне системы) добавления и удаления из списков и инкремента-декремента счётчика.
Для контроля за индексами и кешем нужна отдельная подсистема, индексы обновляются патчами с изменениями, кеш инвалидируется удалением из базы. Опционально индексы хранятся в постоянном хранилище, чтобы не тратить время на реиндексацию при перезапуске.
В итоге, условиям и требуемым возможностям удовлетворяли Redis и Couchbase, но и то, и другое требовало приличного объёма работы напильником и писания дополнительного кода.
С БЭМ знаком не понаслышке, работал с ним довольно много времени.
Начал читать статью и словил лютейший батхёрт от утрированных примеров и самое главное полное отсутствие рассмотрения различных кейсов, таких как рефакторинг, дебаг, приглашение нового человека на проект, перенос функциональностей, интеграцию вёрстки в сторонние проекты и т.д.
Также ничего не мешает юзать препроцессоры вместе с методологией БЭМ, также можно написать свои bemtools, написать свои шаблонизаторы/препроцессоры чтоб они генерили БЕМ-подобную структуру.
Что действительно важно, так это набор соглашений, пусть он будет не БЭМ, но он должен быть, чтоб легко показать как строится проект.
В свою очередь БЭМ несёт очень сжатое количество сущностей в себе и это сильно упрощает восприятие.
Не хочу ставить ни плюс, ни минус за статью: нет четкой постановки вопроса/задачи, нет исследования на примерах, и конечно нет сравнения результатов из примеров.
Не считаю БЭМ идеальной реализацией независимых блоков, но это одна из самых простых, наивных и надёжных конвенций. bemjson в свою очередь тоже весьма и весьма избыточен, но мы ведь о концепции говорим, а не о конкретной реализации, верно?
Не совсем понял восторги от статьи. Прошу простить меня за холодный анализ, я просто надеюсь, что кто-то на волне восторга от статьи прочитает мой комментарий и немного спуститься на землю.
Резюме первой части:
У человека был нормальный бизнес в Кривом Роге, который он бросил, переместился в Киев.
Банерная сеть, которую автор продал.
Потом автору удалось создать хостинг, на поддержку которого он опять забил болт и продал.
Создали веб-студию? Может быть стоило поискать сотрудников, переместившивсь в кресло руководителя? Автор решил, что лучшим решением будет свернуть затею.
Создали сайт? Зачем его развивать, можно же считать что он будет кормить вас до конца жизни. Ведь лучше увлекаться каким-то идеал-методом и играть на гитаре. Опять закономерный итог.
При этом автор не гнушается «инвестициями» в $1.5к в месяц, что говорит скорее всего о том, что много денег с продаж своих сайтов он не получил, либо потратил их ранее. (Конечно, это могло говорить и о том, что он поступает более мудро, и делает ошибки за чужой счет, на растрачивая свои сбережения, однако другие факты в статье говорят в пользу моего первого утверждения).
На этапе поиска исполнителя я обнаружил, что 2 500 — это мало, профи просили 18 000. Но мне всё же удалось найти редкого исполнителя, который согласился за эту сумму воплотить задуманное. Всё шло по плану. Я путешествовал с женой на автомобиле месяц, а фрилансеры кодили.
2 месяца не удается найти никаких инвестиций. А денег осталось всего на месяцев 5. Блин, нужно что-то делать… О! Нужно срочно записать альбом, который тянется уже 2 года
С первым ангелом мы еще на тот момент не оформили официально фирму и не перерегистрировали домен. Но я привык так: если слово дал, значит, держи, даже если это не выгодно. Если бы слово не дал, то конечно сделал бы более удобный выбор в сторону семьи.
Через какое-то время ко мне приходит неожиданная идея. А что если параллельно начать еще один стартап.
Автор сетует на то, что глупые «работники-на-дядю» не хотят принять участие в его прожектах, при этом как-то опуская тот факт, что те крохи, которые он громко называет инвестициями (тут $10к на весь проект, там $10к от ангела, ну еще и $1.5 в месяц), нормальных разработчиков просто смешат, а человек, который усердно ищет инвестиций на сумму, не привышающие две месячные зарплаты «работника-на-дядю» в Киеве, доверия у хороших специалистов не вызывает. Удивительно, что автор совершил несколько раз классическую ошибку и пытался найти полу-бесплатного работника-энтузиаста через онлайн-биржи, назвав его «партнером».
Вместо работы над ошибками, автор попал в водоворот стартапов, где кажется, до миллионов денег рукой подать, а еще можно называть себя CEO, CTO и прочими громкими именами. Какой контраст с одним хорошим человеком, который рулит технарями в крупной американской фирме с многомиллионными оборотами и подписывающим свои письма просто «Боря.».
Но вернемся к автору. Придумав оригинальнуюидею, работающиханалогов у которой, очевидно, нет (что говорит о том, что автор даже поверхностный анализ рынка не провел, да какой анализ, не погуглил даже), автор закачивает где-то мп3-шек (как-то обойдя в статье вопрос лицензирования), нанимает недобросовестного (со слов автора) программиста и побеждает в нескольких конкурсах, получая возможность поработать в каком-то «инкубаторе», описывая это как будто он создал-таки успешный бизнес и вышел на самоокупаемость.
И что происходит далее с сервисом, которому автор посвятил большую часть статьи? Уместив мотивы в один абзац текста, автор в очередной раз забивает болт на идею и меняет ее в сторону Youtube, становясь заложником сервиса с отвратительным качеством звука и кучей ограничений по контенту для СНГ.
Результат — за 2 месяца с февраля по апрель посещаемость выросла со 130 в день до 430 самоходом без рекламы. Это где-то более 100% в месяц.
Простите, 430 уников в день без какого-то намека на доход? Это не 100% рост в месяц, это всего плюс 300 записей в таблице users за два месяца и два месяца чистых убытков.
В общем, лично я для себя составил картину человека, который думает, что создать сайт в интернете тождественно созданию бизнеса, постоянно прыгает с идеи на идею, хорошо умеет пиариться, но при этом боится или не умеет развивать «офлайновое» направление (работу с клиентами, кадрами, составление четких планов развития с опорой на составленные метрики), которое на самом требует подавляющего большинства всех доступных ресурсов. Вместо этого постоянные прыжки по идеям, рок-группа, непостоянные стартап-тусовки с десятью тысячами долларов «инвестиций» (которые можно собрать за пару месяцев работы «на дядю» в Киеве и Москве) и отрицательными доходами по итогу.
Желаю автору стать серьезнее в своих желаниях, послушать курсы или почитать хороших книг по старту и ведению малого бизнеса и забыть это, набившее всем оскомину, слово стартап. Это как раз то, что лежит в пропасти между CTO динамичного стартапа без сотрудников из инкубатора и обычным «дядей». Хотя конечно, рок группы, тусовки по интересам, путешествия выглядят намного привлекательнее, чем работа с кадрами, техническими решениями, бухгалтерией, тоннами метрик, сухими статьями про рынок и работой от заката до рассвета 24/7.
«Не просто», это уже вывод из каких-то более низкоуровневых причин и проблем. Вот мне как раз они интереснее. Что не просто, создавать файлы, или писать длинные селекторы, или разделять всё на блоки, элементы, модификаторы? Если есть возможность показать код проектов (хотя бы лично) было бы вообще круто, тогда более предметно можно разговаривать.
Чем для вас принципы OOCSS отличаются от БЭМ?
Использовать SASS или Stylus можно и с БЭМ: сама методология подразумевает возможность любых технологий реализации блоков (про это не плохо было в недавнем докладе для WebConf в Риге vimeo.com/53219242 + bem.info/articles/yandex-frontend-dev/), а в bem-tools есть поддержка и sass, и styl, и less.
Про свод правил и инструменты я не очень понял противопоставления. Почему или свод правил или инструменты? У нас есть и то и то — вместе только лучше работает.
В офисе ~15 человек, так что всё может быть гораздо менее формально =)
• Каждую пятницу обед за счёт фирмы, ресторан/кафе для заказа еды выбирается дежурным по офису на этой неделе
• Почти каждый день после 5 вечера — пиво за счёт компании
• Раз в неделю (или после сдачи проекта) после 6 вечера — текила/коньяк/самогон, иногда всё вперемешку
• За час до обеда — совместный поход в тренажёрку или пробежка по улицам
• По воскресеньям — заплыв в 6 утра в озере и полумарафонная пробежка после
• Пару раз в год — ЛАН-пати: все вместе гоняем в CoD до 4 утра. Особо ответственные притаскивают из дома свои четырёхъядерные десктопы и 7-канальные наушники с усилитилем и блоком питания
• Шахматы, фузбол — по желанию
• По вторникам — баскетбол после работы
• Фэнтэзи-футбол/баскетбол/хоккей, проигравшие делают что-то оговорённое зарание (например, признаются в фанатстве Биберу на Фейсбуке)
• Картинг — раз в год, всей командой
• Пикник — раз в год, всей командой + половинки
• Пару досок в офисе оставлены под имиджборды (только рисовать самому надо, прикрепить картинку нельзя)
• Все друг другу раздают пять сверху, когда приходят на работу и когда уходят
• Музыка в офисе иногда ставится тематически — например, лучшее из 80-х или 90-х
• Темы для обсуждения за обедом — самые разнообразные: от проектов и клиентов до лучших способах самоубийства и почему не стоит давать милостыни бомжам
• www.youtube.com/watch?v=w8rrFzA5kYs
Полностью поддерживаю.
Смотрел видео одного тренинга, там достаточно умный дядька доводил до аудитории простую мысль (сейчас я вам сэкономлю 40000 рублей стоимости этого тренинга):
мотивации НЕ существует.
Если ты говоришь, что чего-то хочешь, но у тебя этого нет — значит, ты этого не хочешь.
«Вот, у меня в квартире убираться не получается, мне лень, как мне быть, как мне себя замотивировать..»
Никак.
Это твой собственный выбор по твоему собственному желанию. Либо ты выбрал убраться в квартире, и она чистая. Либо ты выбрал не убираться, и она грязная.
Либо тебе работа нравится и ты её делаешь с удовольствием и увлечением. Либо не нравится, и никакие гдт гибдд итд гкчп тебе не помогут.
«Я выбрал откладывать работу, так как она мне не нравится, и трачу время впустую».
«Я выбрал дописать эту программу, и это принесло мне удовлетворение».
В общем, только действия показывают реальность. Либо ты что-то сделал, либо ты этого не сделал.
Как-то так.
Полностью согласен. Но решил узнать мнение ибо может что-то поменялось, а я упустил. Все-таки без кавычек читается все адски ужасно.
Так как времени на споры нет, надо работать, тоя просто сделал такой вот финт руками:
for f in $(ls -l)
do
f=${f%*.html}
fv=${f}_valid.html
sed -r 's~(class|href|src|target|rel|name|lang|charset|title|width|height|alt)=([^"][a-z0-9\-\/:.?&\#а-яёА-ЯЁ_]+)(\s|\/|>)~\1="\2"\3~gi' $f.html > $fv
done
О я тоже был в Квебек сити на матче с чехами, классная игра была. В Квебек сити кстати очень мало людей понимают английский, даже молодежь плохо говорит. Мы ходили там по городу смотрели достопримечательности и к нам подходили люди и спрашивали не хоккеисты ли мы. Так мы сначала отнекивались, а потом надоело. И если кто спрашивал мы отвечали что да хоккеисты, сборная Белоруссии. Мы в клуб опоздали на 2 часа только из за того что раздавали автографы:)))))))))
А мне нравятся рекрутеры — они такие забавные :) Вы просто представьте их внутренний мир: они искренне считают, что «находятся на острие кадровой политики компании». Так что где-то их даже жалко.
Сам я побывал и в роли того, кто «заказывает» кадры, и в роли, собственно, интервьюируемого.
Во времена соискательства я твердо вывел для себя несколько железных правил
1. общение с рекрутером не должно длиться более 5 минут. Если больше — компания мне не подходит (в силу узкой специфики профессии недостатка предложений не было). Это правило позволило мне сберечь немало нервов и времени.
2. Не ждать встречи более 10 минут. Если назначивший встречу человек опаздывает более чем на 10 минут — продолжать общение нет смысла. Он явно не уважает мое время. И кстати, что самое смешное, если развернуться и уйти — потом звонят, многословно извиняются, и просят назвать удобное время.
3. Не заполнять анкет и бумаг. В конце концов это работа рекрутера — а я могу так и быть надиктовать. Опять-таки правило очень экономит время и нервы — обидно выполнять бесплатно бессмысленную работу.
4. Псевдо-психологические игры не для меня. При первых попытках их начать надо просто встать, извиниться, и сказать что в этой компании я едва ли смогу работать.
5. Всегда общаться только с непосредственным руководителем. Ибо остальные — никто с точки зрения соискателя.
Эти простые правила в моем конкретном случае сработали очень неплохо, ибо последние несколько лет я сам уже заказывал рекрутерам сотрудников, и при этом никогда не забывал становиться на место соискателя.
При заказе я всегда старался свести к минимуму роль рекрутера — на мой взгляд единственная реальная его задача — отсеять людей совсем уж невменяемых. А остальных аккуратно представить пред мои очи.
В итоге получилось собрать очень сильную и приятную в работе команду.
У русских менталитет такой, поддерживать и сопереживать более слабому, чтобы потом втройне порадоваться редкой, но оттого более ценной победе. На западе люди не будут сопереживать слабому, посчитают его поражение закономерным. И почти всегда будут покланяться и поддерживать лидера. Такое там почти повсеместно.
Обычно на форумах, когда что-то выкладывают, заливают на файлообменники. Торренты на форумах используют чуть реже. У меня в основном трафф входящий идет только с рапиды. Поэтому приходится пользоваться платными акками.
Суть:
«Современные методы сводятся к проверке умственного уровня и психологической беседе. Недостаток вышеозначенной проверки в том, что победители не знают совершенно ничего.
Наблюдателям могут угодить лишь скрытные мелочные субъекты себе на уме, которые мало говорят и ничего не делают. При таком методе нередко из пятисот человек выбирают именно того, кто через несколько недель окажется абсолютно непригодным. Без всякого сомнения, этот метод хуже всех.
Какой же метод применять нам в будущем?… Но суть тут в том, что все заявления выбрасывают в корзину, а речь пойдет лишь о человеке, который заявления не подавал.
Нет никакой возможности выбрать одного из трехсот умелых людей, снабженных прекрасными характеристиками. Приходится признать, что система неверна изначально. Незачем привлекать такую массу народу. Но никто об этом не знает, и объявления составлены так, что они неизбежно приманят тысячи.
Легче и выгодней было бы подумать сразу.
Если же подумать, увидишь, что идеальное объявление привлечет одного человека, и того именно, кто нужен. Начнем с предельного случая:
»Требуется акробат, который может пройти по проволоке на высоте 200 м над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет. Явиться лично в цирк «Дикий Кот» от 9 до 10".
Быть может, слог и не очень хорош, но цель ясна: нужно так уравновесить риском денежную выгоду, чтобы не явилось больше одного соискателя.
Если все написать как следует, придет только один соискатель и сможет сразу или почти сразу приступить к работе. А если не придет никто? Значит, надо написать иначе, в чем — то мы завысили требования. То же самое небольшое объявление предложим в измененном виде. "
Ничего лучше id и ссылки на них для исключения дублирования не придумали.
Хранилище требует три основных типа данных:
— Документ, тип которого дополнительно определяется классом допумента
— Список из id, имеет атомарное добавление и опционально атомарное удаление
— Счётчик атомарно изменяемый целочисленный.
— Дополнительно не помешает Массив, аналогичен списку с произвольным типом.
Документ есть данные, относящиеся напрямую к объекту. Остальное хранится с помощью ссылки на списки.
От хранилища требуются крайне быстрые и эффективные операции класса «достать по ключу» и «записать по ключу».
Для сложных запросов нужна отдельная система индексов, хранимых в быстрой памяти. Индекс состоит из пар ключ-id упорядоченных по ключу. В некоторых случаях индекс позволяет избежать запросов к спискам.
Непротиворечивость и согласованное состояние гарантируется атомарностью (на уровне системы) добавления и удаления из списков и инкремента-декремента счётчика.
Для контроля за индексами и кешем нужна отдельная подсистема, индексы обновляются патчами с изменениями, кеш инвалидируется удалением из базы. Опционально индексы хранятся в постоянном хранилище, чтобы не тратить время на реиндексацию при перезапуске.
В итоге, условиям и требуемым возможностям удовлетворяли Redis и Couchbase, но и то, и другое требовало приличного объёма работы напильником и писания дополнительного кода.
я использую 2х — namecheap.com и joker.com
Начал читать статью и словил лютейший батхёрт от утрированных примеров и самое главное полное отсутствие рассмотрения различных кейсов, таких как рефакторинг, дебаг, приглашение нового человека на проект, перенос функциональностей, интеграцию вёрстки в сторонние проекты и т.д.
Также ничего не мешает юзать препроцессоры вместе с методологией БЭМ, также можно написать свои bemtools, написать свои шаблонизаторы/препроцессоры чтоб они генерили БЕМ-подобную структуру.
Что действительно важно, так это набор соглашений, пусть он будет не БЭМ, но он должен быть, чтоб легко показать как строится проект.
В свою очередь БЭМ несёт очень сжатое количество сущностей в себе и это сильно упрощает восприятие.
Не хочу ставить ни плюс, ни минус за статью: нет четкой постановки вопроса/задачи, нет исследования на примерах, и конечно нет сравнения результатов из примеров.
Не считаю БЭМ идеальной реализацией независимых блоков, но это одна из самых простых, наивных и надёжных конвенций. bemjson в свою очередь тоже весьма и весьма избыточен, но мы ведь о концепции говорим, а не о конкретной реализации, верно?
Резюме первой части:
При этом автор не гнушается «инвестициями» в $1.5к в месяц, что говорит скорее всего о том, что много денег с продаж своих сайтов он не получил, либо потратил их ранее. (Конечно, это могло говорить и о том, что он поступает более мудро, и делает ошибки за чужой счет, на растрачивая свои сбережения, однако другие факты в статье говорят в пользу моего первого утверждения).
Автор сетует на то, что глупые «работники-на-дядю» не хотят принять участие в его прожектах, при этом как-то опуская тот факт, что те крохи, которые он громко называет инвестициями (тут $10к на весь проект, там $10к от ангела, ну еще и $1.5 в месяц), нормальных разработчиков просто смешат, а человек, который усердно ищет инвестиций на сумму, не привышающие две месячные зарплаты «работника-на-дядю» в Киеве, доверия у хороших специалистов не вызывает. Удивительно, что автор совершил несколько раз классическую ошибку и пытался найти полу-бесплатного работника-энтузиаста через онлайн-биржи, назвав его «партнером».
Вместо работы над ошибками, автор попал в водоворот стартапов, где кажется, до миллионов денег рукой подать, а еще можно называть себя CEO, CTO и прочими громкими именами. Какой контраст с одним хорошим человеком, который рулит технарями в крупной американской фирме с многомиллионными оборотами и подписывающим свои письма просто «Боря.».
Но вернемся к автору. Придумав оригинальную идею, работающих аналогов у которой, очевидно, нет (что говорит о том, что автор даже поверхностный анализ рынка не провел, да какой анализ, не погуглил даже), автор закачивает где-то мп3-шек (как-то обойдя в статье вопрос лицензирования), нанимает недобросовестного (со слов автора) программиста и побеждает в нескольких конкурсах, получая возможность поработать в каком-то «инкубаторе», описывая это как будто он создал-таки успешный бизнес и вышел на самоокупаемость.
И что происходит далее с сервисом, которому автор посвятил большую часть статьи? Уместив мотивы в один абзац текста, автор в очередной раз забивает болт на идею и меняет ее в сторону Youtube, становясь заложником сервиса с отвратительным качеством звука и кучей ограничений по контенту для СНГ.
Простите, 430 уников в день без какого-то намека на доход? Это не 100% рост в месяц, это всего плюс 300 записей в таблице users за два месяца и два месяца чистых убытков.
В общем, лично я для себя составил картину человека, который думает, что создать сайт в интернете тождественно созданию бизнеса, постоянно прыгает с идеи на идею, хорошо умеет пиариться, но при этом боится или не умеет развивать «офлайновое» направление (работу с клиентами, кадрами, составление четких планов развития с опорой на составленные метрики), которое на самом требует подавляющего большинства всех доступных ресурсов. Вместо этого постоянные прыжки по идеям, рок-группа, непостоянные стартап-тусовки с десятью тысячами долларов «инвестиций» (которые можно собрать за пару месяцев работы «на дядю» в Киеве и Москве) и отрицательными доходами по итогу.
Желаю автору стать серьезнее в своих желаниях, послушать курсы или почитать хороших книг по старту и ведению малого бизнеса и забыть это, набившее всем оскомину, слово стартап. Это как раз то, что лежит в пропасти между CTO динамичного стартапа без сотрудников из инкубатора и обычным «дядей». Хотя конечно, рок группы, тусовки по интересам, путешествия выглядят намного привлекательнее, чем работа с кадрами, техническими решениями, бухгалтерией, тоннами метрик, сухими статьями про рынок и работой от заката до рассвета 24/7.
Чем для вас принципы OOCSS отличаются от БЭМ?
Использовать SASS или Stylus можно и с БЭМ: сама методология подразумевает возможность любых технологий реализации блоков (про это не плохо было в недавнем докладе для WebConf в Риге vimeo.com/53219242 + bem.info/articles/yandex-frontend-dev/), а в bem-tools есть поддержка и sass, и styl, и less.
Про свод правил и инструменты я не очень понял противопоставления. Почему или свод правил или инструменты? У нас есть и то и то — вместе только лучше работает.
Если приложение в большей степени на JS, то БЭМ вполне может помочь. У нас часть про клиентский JS не плохо проработана на практике (например, при создании n.maps.yandex.ru — тоже не простой интерфейс). Про это есть несколько докладов: events.yandex.ru/events/yasubbotnik/msk-jul-2012/talks/302/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/323/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/324/.
• Каждую пятницу обед за счёт фирмы, ресторан/кафе для заказа еды выбирается дежурным по офису на этой неделе
• Почти каждый день после 5 вечера — пиво за счёт компании
• Раз в неделю (или после сдачи проекта) после 6 вечера — текила/коньяк/самогон, иногда всё вперемешку
• За час до обеда — совместный поход в тренажёрку или пробежка по улицам
• По воскресеньям — заплыв в 6 утра в озере и полумарафонная пробежка после
• Пару раз в год — ЛАН-пати: все вместе гоняем в CoD до 4 утра. Особо ответственные притаскивают из дома свои четырёхъядерные десктопы и 7-канальные наушники с усилитилем и блоком питания
• Шахматы, фузбол — по желанию
• По вторникам — баскетбол после работы
• Фэнтэзи-футбол/баскетбол/хоккей, проигравшие делают что-то оговорённое зарание (например, признаются в фанатстве Биберу на Фейсбуке)
• Картинг — раз в год, всей командой
• Пикник — раз в год, всей командой + половинки
• Пару досок в офисе оставлены под имиджборды (только рисовать самому надо, прикрепить картинку нельзя)
• Все друг другу раздают пять сверху, когда приходят на работу и когда уходят
• Музыка в офисе иногда ставится тематически — например, лучшее из 80-х или 90-х
• Темы для обсуждения за обедом — самые разнообразные: от проектов и клиентов до лучших способах самоубийства и почему не стоит давать милостыни бомжам
• www.youtube.com/watch?v=w8rrFzA5kYs
И да, мы работаем =)
Думайте, когда пишите
Dojo — dojotoolkit.org/reference-guide/dojo/declare.html#dojo-declare
Sencha (ExtJS) — www.rogerwilco.ru/2011/04/sencha-extjs.html
qooxdoo — qooxdoo.org/documentation/0.7/oo_feature_summary
MooTools — www.phpeveryday.com/articles/MooTools-Basic-Creating-Classes-MooTools-P919.html
Prototype — www.prototypejs.org/learn/class-inheritance
AtomJS — github.com/theshock/atomjs/blob/master/Docs/Class/Class.md
JSClass — jsclass.jcoglan.com/classes.html
code.google.com/p/jsclassextend/
github.com/jcoglan/js.class
Cobra — justin.harmonize.fm/index.php/2009/01/cobra-a-little-javascript-class-library/
github.com/JustinTulloss/cobra
The $class Library- www.uselesspickles.com/class_library/
Classy — classy.pocoo.org/
YUI 3 — www.yuiblog.com/blog/2010/01/06/inheritance-patterns-in-yui-3/
Coffee-Script — jashkenas.github.com/coffee-script/#classes
JavascriptClasses — code.google.com/p/javascript-classes/
AJS — amix.dk/blog/post/19038
jsFace — github.com/tannhu/jsface
JsOOP — jsoop.codeplex.com/
joot — code.google.com/p/joot/wiki/API
oopsjs — code.google.com/p/oopsjs/
Objs — github.com/tekool/objs/wiki
oorja — maxpert.github.com/oorja/
objx — code.google.com/p/objx/wiki/OClass
jsclassextend — code.google.com/p/jsclassextend/
prolificjs — code.google.com/p/prolificjs/wiki/OOP
objectize — code.google.com/p/objectize/
code.google.com/p/core-framework/wiki/Inheritance
code.google.com/p/sfjsoo/
code.google.com/p/jslproject/
code.google.com/p/magic-classes/wiki/MagicClassesOverview
github.com/ded/klass
github.com/jiem/my-class
github.com/kilhage/class.js
github.com/Jakobo/Sslac
github.com/BonsaiDen/neko.js
github.com/finscn/GT-Class
github.com/deadlyicon/klass.js
github.com/neuromantic/CodeJS
github.com/cj/js-oo
github.com/darthapo/klass.js
github.com/nemisj/zet.js
github.com/k33g/species
github.com/benekastah/JS-Class
github.com/tobeytailor/def.js
github.com/rstrobl/squeakyJS
github.com/shinyplasticbag/MojoClass
github.com/firejune/class
github.com/gcoguiec/jquery-class
github.com/daffl/JS.Class
github.com/pavelz/class.js
github.com/zerodogg/jqsimple-class
github.com/bnoguchi/class-js
github.com/arian/Klass
github.com/kuwabarahiroshi/joo
github.com/iamleppert/SimpleClass
github.com/aenoa/Noode.js
github.com/stomlinson/SuperClass
github.com/jzimmek/klazz
github.com/kbjr/class.js
github.com/jhnns/node.class
github.com/borysf/declare/blob/master/declare.js
github.com/ShadowCloud/BF-Class
github.com/pic-o/jsClass
github.com/rosamez/jquery.klass
github.com/yuki-kimoto/javascript-Class_Simple
github.com/yaksnrainbows/jarb
github.com/thirashima/UnderClass
github.com/arahaya/package.js
github.com/arieh/Class.def
github.com/bogdan-dumitru/jsClass
github.com/pomke/pomke.js
github.com/sgolasch/jClassify
github.com/kbjr/Classy
github.com/cthackers/jClass
github.com/davidjbeveridge/Clasico
github.com/edave64/protojazz
github.com/mrac/solid.js
github.com/benekastah/Classy
github.com/damianmr/JSMiniClass
github.com/benekastah/classesWithCash
github.com/dialog/Resig-Class
github.com/mpodriezov/OJS
github.com/dtinth/twcs.js
github.com/percyhanna/js-class
github.com/jalopez/SimpleClassJS
github.com/jhamlet/proteus
github.com/petebrowne/classify
github.com/TdroL/Classy.js
github.com/azendal/neon
github.com/aulizko/Alan-Point-JavaScript-Library/tree/master/src/oop
Смотрел видео одного тренинга, там достаточно умный дядька доводил до аудитории простую мысль (сейчас я вам сэкономлю 40000 рублей стоимости этого тренинга):
мотивации НЕ существует.
Если ты говоришь, что чего-то хочешь, но у тебя этого нет — значит, ты этого не хочешь.
«Вот, у меня в квартире убираться не получается, мне лень, как мне быть, как мне себя замотивировать..»
Никак.
Это твой собственный выбор по твоему собственному желанию. Либо ты выбрал убраться в квартире, и она чистая. Либо ты выбрал не убираться, и она грязная.
Либо тебе работа нравится и ты её делаешь с удовольствием и увлечением. Либо не нравится, и никакие гдт гибдд итд гкчп тебе не помогут.
«Я выбрал откладывать работу, так как она мне не нравится, и трачу время впустую».
«Я выбрал дописать эту программу, и это принесло мне удовлетворение».
В общем, только действия показывают реальность. Либо ты что-то сделал, либо ты этого не сделал.
Как-то так.
Так как времени на споры нет, надо работать, тоя просто сделал такой вот финт руками:
for f in $(ls -l)
do
f=${f%*.html}
fv=${f}_valid.html
sed -r 's~(class|href|src|target|rel|name|lang|charset|title|width|height|alt)=([^"][a-z0-9\-\/:.?&\#а-яёА-ЯЁ_]+)(\s|\/|>)~\1="\2"\3~gi' $f.html > $fv
done
Сам я побывал и в роли того, кто «заказывает» кадры, и в роли, собственно, интервьюируемого.
Во времена соискательства я твердо вывел для себя несколько железных правил
1. общение с рекрутером не должно длиться более 5 минут. Если больше — компания мне не подходит (в силу узкой специфики профессии недостатка предложений не было). Это правило позволило мне сберечь немало нервов и времени.
2. Не ждать встречи более 10 минут. Если назначивший встречу человек опаздывает более чем на 10 минут — продолжать общение нет смысла. Он явно не уважает мое время. И кстати, что самое смешное, если развернуться и уйти — потом звонят, многословно извиняются, и просят назвать удобное время.
3. Не заполнять анкет и бумаг. В конце концов это работа рекрутера — а я могу так и быть надиктовать. Опять-таки правило очень экономит время и нервы — обидно выполнять бесплатно бессмысленную работу.
4. Псевдо-психологические игры не для меня. При первых попытках их начать надо просто встать, извиниться, и сказать что в этой компании я едва ли смогу работать.
5. Всегда общаться только с непосредственным руководителем. Ибо остальные — никто с точки зрения соискателя.
Эти простые правила в моем конкретном случае сработали очень неплохо, ибо последние несколько лет я сам уже заказывал рекрутерам сотрудников, и при этом никогда не забывал становиться на место соискателя.
При заказе я всегда старался свести к минимуму роль рекрутера — на мой взгляд единственная реальная его задача — отсеять людей совсем уж невменяемых. А остальных аккуратно представить пред мои очи.
В итоге получилось собрать очень сильную и приятную в работе команду.