Трудно вспомнить, когда и за какими напитками нам впервые пришла в голову мысль, что если все лето путешествовать не получается, и в перерыве между поездками все равно нужно работать, то нужно делать это в любимых нами Ладожских шхерах. Но в прошлом году мы это сделали — организовали на месяц коворкинг-офис на гранитном основании. И повторяем в этом году. По дороге мы приобрели некоторый опыт, который и хотим обобщить в этой статье. Мало ли, пригодится кому.

Около полугода назад мне задали примерно такой вопрос: “Я использую крупный фреймворк, запускающий некую функцию по действию пользователя. Хочу, не меняя кода этой функции, выполнить по событию вызова этой функции свой код.”. Практика далеко не лучшая, события вызова функции не существует, я просто покрутил пальцем у виска и сказал, что это жуткий говнокод, так делать не стоит, да и это, просто-напросто, — невозможно.

Пару дней назад, направляясь домой относительно тёплым зимним вечером, не типичным для Одессы, у меня возникла нетипичная мысль: “А что если попробовать сделать то, что спрашивал Богдан полгода назад?”. Придя домой, я включил компьютер, и, в течении пары минут, сделал то, что задумал. В первую очередь, меня интересовало то, как будут себя вести встроенные методы, если их переопределить, и можно ли после этого как-нибудь вызвать прежнее их состояние, бывшее до переопределения. Я знал, что, если объект переопределяют, то ссылки на него не уничтожатся, сохраняя прежний вид. Что касается встроенных функций, имелись сомнения. Оказывается, можно.

Скорее всего, мне даже никогда не придется воспользоваться таким инструментом, но, чисто гипотетически, возможно, у кого-то возникнет задача проследить вызов той или иной функции, получив отчет о каждом вызове, состоящий из:

1. Результата выполнения
2. Переданных аргументов
3. Контекста вызова (что есть this при вызове)
4. Количества вызовов функции после создания обработчика

(Этот список полностью соответствует аргументам, передающимся в обработчик)

Первое впечатление — это все. Пословица «По одежке встречают, по уму провожают» актуальна не только в жизни, но и в дизайне. Впечатление от дизайна состоит из множества факторов, и один из важнейших — это цвет.

Понять, какие цвета сочетаются друг с другом не всегда просто, в этой статье описаны основы теории цвета, которые пригодятся при выборе цветовой схемы для дизайна сайта. Начнем с самого простого.

Основные цвета (Primary Colors)

Основные цвета палитры — красный, желтый и синий. Если говорить об основных цветах на экранах различных устройств — это RGB, красный, зеленый и синий.

Чуть более месяца назад я устроился верстальщиком в старт-ап, в команду Ruby-разработчиков. Так повезло, что команда оказалась очень хорошей и моё стремление учиться совпало с их желанием получить хорошего специалиста.

HTML-вёрстка сама по себе имеет немного ценности и не единственное, чем можно нагрузить верстальщика.

На нашем сайте пользователь оформляет себе покупку и ему на почту уходит подтверждение с электронным билетом. в котором указаны детали заказа, а так как в хорошем проекте всё должно быть хорошо и ярко, дизайнер нарисовал макет квитанции. Ну а мне, как верстальщику было поручено реализовать это всё в коде.

Варианты генераторов для Ruby

Согласно сайту Ruby Toolbox существует два принципиальных подхода к генерации PDF-файлов:

• wkhtmltopdf и различные обёртки на него
• Prawn

Первый вариант подразумевает генерацию HTML-страницы и конвертацию её в PDF, в то время как второй позволяет, по факту, работать с canvas и генерировать документ без дополнительных прослоек.

Я выбрал вариант с использованием Prawn (по большей части, конечно, по тому, что предыдущая версия PDF-файла генерировалась этим способом) даже не смотря на то, что мне пришлось вынырнуть из привычного мне мира HTML и CSS

Тех, кому интересно приглашаю под хабракат.

Про 3Д принтеры написано уже воз и малая тележка, но когда начинаешь собирать самостоятельно — сталкиваешься с кучей вопросов и проблем, которые нигде не описаны…
Данный пост — маленькое пособие для начинающих РепРаперов (ну и остальным что-то пригодится) про шишки, которые я набивал при сборке своего RepRap Prusa Mendel.

В статье «12 тыс рублей за сайт. Есть ли бизнес за МКАДом?» я писал про наш подход к разработке сайтов на базе разработанной внутри компании технологии. На момент написания той статьи, мы выпускали «под ключ» 24 сайта в месяц. Это больше чем один сайт в день силами команды из 8 человек.

После рассказа на хабре о нашей технологии количество заявок на разработку сайтов выросло в несколько раз. Только за март 2012 было выставлено около 60-ти коммерческих предложений и, большая часть из них превращалась в договора.

И тут наше производство затрещало по швам. Практически сразу заявки стали становиться в очередь, менеджеры начали путаться в проектах, дизайнеры стали проситься в отпуск. Ситуация становилась поистине напряженной…

Вступление

К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:

• выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
  
• и презентацию Сергея Бережного
  «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.
  

Статья содержит такие разделы:

• Украинские реалии при выполнении проекта
• Проблемы и их решения
• Подготовка к оценке
• Перечень работ для оценивания
• Оценка работ по написанию кода
• Цифры и коэффициенты из практики
• Пример расчета

Конечно же расписание и бюджет важны. Если расписание проекта не важно, попросите ваших коллег позвонить вам через два года, когда проект закончится :).

Никогда не обращали внимание, как часто старые интерфейсы, старый код и вообще старые решения выглядят странными и уродливыми? Причём всё это может стать старым за считанные годы. Когда приходится очень быстро бежать только, чтобы оставаться на месте, возникает желание как-нибудь срезать, заглянуть немного в будущее, перепрыгнуть через пару пунктов.

Давайте попробуем. Для этого нам необходимо понять по каким принципам идет развитие: внимательно рассмотреть те пещерные технологии, что мы использовали пару лет назад и то, как они превращались в “технологии будущего”, что мы используем сегодня.

За последнюю неделю дважды объяснял людям как организована работа с памятью в х86, с целью чтобы не объяснять в третий раз написал эту статью.

И так, чтобы понять организацию памяти от вас потребуется знания некоторых базовых понятий, таких как регистры, стек и тд. Я по ходу попробую объяснить и это на пальцах, но очень кратко потому что это не тема для этой статьи. Итак начнем.