От переводчка: наткнулся на показавшийся интересным вымышленный рассказ человека из будущего, который ездил только на электромобилях и решил купить недорогой бензиновый авто. Для простоты я решил везде писать «бензиновый авто», хотя подразумевается, конечно, автомобиль на жидком топливе.

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

Мы садимся в автомобиль в офисе продаж. Кстати, бензиновый автомобиль нельзя купить напрямую автопроизводителя, необходимо обязательно обращаться к перекупщикам в ремонтную мастерскую, так называемым, официальным дилерам. По мне так это плохой знак, покупать авто в ремонтной мастерской, которую, по идее, вы желаете посещать как можно реже. Но как я уже сказал, напрямую у производителя купить автомобиль нельзя. Кстати продавец оказался очень настойчивым и буквально «заставлял» нас купить автомобиль.

В недавнем посте о восстановлении работы git-репозитория Android многие жаловались, что пока нет веб-интерфейса доступа к исходникам из Windows тоже нет. Это не так, git под Windows есть и их можно легко забрать. Единственное что не работает без пинка — это repo, который весьма удобен для выкачивания сырцов. Однако пинок требуется минимальный, имя пинку — Cygwin. Этот пост о том, как поставить Cygwin с нуля, какие пакеты выбрать для работоспособности repo и как всё выкачать пользователям Windows. Для понимания поста требуется умение работать с консолью на базовом уровне, понимать что такое приглашение, уметь печатать текст и жать Enter.

Взято отсюда специально для хабра. Возможно, в некоторых из ситуаций вы узнаете себя.

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Привет, Хабрасообщество!

У меня вот уже больше 10 лет горит идея сделать такой проект Умного Дома, чтобы любой желающий мог при желании собрать полный прототип из подручных материалов.
Совсем недавно, при общении с некоторыми представителями хабрасообщества, идея была скорректирована под то, что не плохо бы сделать некий массовый блог, где каждый смог бы оставлять свои идеи по поводу реализаций (под это дело я сегодня даже поднял лайвстрит на субдомене своего личного домена, ибо пока не придумал названия для проекта с учётом его новой специфики) + к этому некое хранилище проверенных проектов (на гитхабе. Уже даже есть Gentoo'шный layman'овский репозиторий под это дело) + к этому некую «биржу», где люди далёкие от паяльных дел, но желающие умный дом, могли бы найти желающих чуток подзаработать мастеров паяльного дела в своём городе :).
Дополнительным бонусом являлось бы объединение (по возможности всех) людей, занимающихся этой тематикой «под одной крышей» для обмена идеями и опытом.

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

Моя карьера стартовала в самом начале нулевых, в течение 6 лет я работал программистом и консультантом разных уровней, а примерно 5 лет назад я полностью перепрофилировался в менеджера. Решение уходить из чисто технической области, как и многие, я принимал под впечатлением иллюзий о том, что у менеджеров намного больше денег, больше возможностей принимать решения и т.д. Как и писал TheR в упомянутом выше посте, многие мои предположения о работе менеджером оказались иллюзией, но некоторое количество очевидных (и не очень) плюшек в этой профессии все же присутствует. Я надеюсь, что эти два поста про плюсы и минусы такого перепрофилирования помогут кому-нибудь из Хабровчан принять взвешенное решение о дальнейшем развитии своей карьеры.

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

Боевая задача.

Предположим нам хочется захостить небольшой проектик где-нибудь в надежном и не особо тормозящем месте. А поскольку сайт небольшой, то не будем заморачиваться и захотим от хостинга что-нибудь самое простое. Для наших целей вполне хватит PHP, MySQL и доступа по FTP.
Для решения этой задачи идеально подходит Веб сервис от Амазона в котором удивительным образом сочетается способность выдерживать большие нагрузки с бесплатным пакетом ресурсов на первый год после регистрации. В бесплатный пакет входит много чего, но в данный момент нас будут интересовать:

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

Причем все это при желании можно зарегистрировать и подготовить к работе за полчаса, но понадобится кредитная карта, которую примет Amazon (и снимет 2 доллара) и сотовый телефон под рукой (домашний не подойдет).

Введение

В жизни любого крупного веб-проекта, особенно на PHP, но, в целом, это касается любого серверного ЯП, пригодного для веб-разработки, обычно наступает понимание, что «так дальше жить нельзя», и что настал момент, когда нужно провести оптимизацию работы сайта, чтобы он перестал тормозить (хотя бы на production).

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

Если вы смогли определить, что это — ваш случай, и ваш проект на MySQL, то эта статья может вам помочь принять конкретные меры и исправлению ситуации с закреплением результата и предотвращением возникновения откровенных проблем с СУБД впоследствии.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

В продолжение начатой темы про собственную поисковую машину

Итак есть несколько крупных задач, которые должна решить система поиска, начнем с того что отдельную страницу надо получить и сохранить.
Тут есть несколько способов, в зависимости от того, какие способы обработки Вы выберете в дальнейшем.

Очевидно, надо иметь очередь страниц, которые надо загрузить из web, хотя бы для того чтобы потом на них смотреть длинными зимними вечерами, если ничего лучшего не придумать. Я предпочитаю иметь очередь сайтов и их главных страниц, и локальную мини очередь того что я буду обрабатывать в данное время. Причина проста – список всех страниц которые я хотел бы загрузить просто за месяц – может существенно превысить объем моего немаленького винчестера :), поэтому я храню только то что действительно необходимо – сайты, их на данный момент 600 тысяч, и их приоритеты и времена загрузки.

Когда-то давно взбрела мне в голову идея: написать свой собственный поисковик. Было это очень давно, тогда я еще учился в ВУЗе, мало чего знал про технологии разработки больших проектов, зато отлично владел парой десятков языков программирования и протоколов, да и сайтов своих к тому времени было понаделано много.

Ну есть у меня тяга к монструозным проектам, да…

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

На данный момент у меня есть собственный, обучающийся поисковик от и до, со многими нюансами – подсчетом PR, сбором статистик-тематик, обучающейся функцией ранжирования, ноу хау в виде отрезания несущественного контента страницы типа меню и рекламы. Скорость индексации примерно полмиллиона страниц в сутки. Все это крутится на двух моих домашних серверах, и в данный момент я занимаюсь масштабированием системы на примерно 5 свободных серверов, к которым у меня есть доступ.