Тихим, теплым, вечером разрабатывая систему кэширования через memcached и добавляя сервер меня вдруг посетила мысль.

С чего все начиналось

А все началось с того, что я перешел с Debian семейства к семейству RHEL. Примерно неделю назад я первый раз своими руками(не могу сказать что на Ubuntu это было своими руками) поднял сервер для разработки проекта. Я своими руками правил конфиги nginx, apache, php — раньше на Ubuntu все ставилось в пару команд и работало само. Впрочем, правя конфиги, я стал лучше понимать, как оно там все работает. Наверное это меня и подтолкнуло к мысли о memcached.

Похоже на этой неделе волна постов изменялок интерфейса Хабра. Напишу и про свою.

Иногда так бывает, что открываешь пост, а там уже сотни комментариев, а времени и желания читать всё нет, или тема не особо интересная чтобы тратить на неё много времени. Хочется посмотреть только самые интересные комментарии.

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

Всем доброго времени суток. Как-то так получилось, за последнее время я увидел много интересных и полезных инструментов/библиотек/событий, которыми я хотел поделиться на Хабре. Все эти темы по отдельности, на мой взгляд, не заслуживали целой статьи. Но каждая из них достойна внимания и может кому нибудь пригодиться. В итоге получился небольшой дайджест:

Prepros

Великолепное приложение препроцессор для CSS, JS. Компилирует файлы следующих типов: LESS, Sass, SCSS, Stylus, Jade, Slim, Coffeescript, LiveScript, Haml. Минифицирует JS на лету, при каждом изменении файла. Оптимизирует изображения. Доступен для Windows и Mac, а также как расширение для Chrome. Плюс ко всему создает HTTP сервер, для тестирования сайта на разный устройствах. Бесплатная замена CodeKit'у и Ghostlab'у вместе взятых, что в сумме позволит Вам сэкономить $75.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.

Короче, мы застреваем в спагетти-коде. К счастью, есть современные JS-фреймворки (библиотеки, задающие, кроме функций, правила организации кода --прим. перев.), помогающие поддерживать структуру и организованность в проекте, облегчающие ремонтопригодность в будущем.

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

Совсем недавно мы отрелизили на hh.ru зарплатные кластеры, которые помогают оценить свою стоимость как специалиста. Это достаточно интересная и гибкая фича, такая, что с ее помощью даже можно провести небольшое исследование рынка труда, определив своё место в нем:

Этот пост навеян оценкой большого технологического проекта, в которой мне довелось поучаствовать. Оценка началась катастрофически – после недель совещаний, сборов рабочих групп и размышлений тимлидов разработка представила оценку сроков разработки – с разбросом в 14 месяцев между минимальной и максимальной длительностью проекта.

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

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

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

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

(<([a-z]+[^>]*)>)(.*)(</\2>)

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



Когда-то и мне пришлось по долгу службы подружиться с регулярными выражениями. Прочитав Фридла и несколько статей на Хабре, я, конечно, начал понимать этот синтетический язык. Тем не менее, каждый раз, когда приходилось написать очередную регулярку, я быстро закапывался в нагромождении скобок, слешей, точек, плюсов, знаков вопроса, и других хорошо вам знакомых конструкциях. Разобраться в этой каше было очень сложно, особенно если возвращаешься к задаче месячной давности. Я мечтал об инструменте, который помог бы мне разобраться в собственном творении. Приблизительно подходящих по смыслу сервисов нагуглилось с десяток, но все они приносили мало пользы. Как раз тогда я и начал разрабатывать этот проект.

Итак, regexponline – инструмент, способный наглядно изобразить структуру регулярного выражения, разобрав его по элементарным компонентам; продемонстрировать совпадающие и не совпадающие его части; помочь в написании и отладке выражения, которое почему-то не совпадает с нужной строчкой.

В Интернет можно найти множество различающихся реализаций и схем, уже набившего оскомину, паттерна MVC. В разных книгах я также встречал разные схемы. Это порождает некоторую путаницу и комментарии к моей предыдущей статье: "Реализация MVC паттерна на примере создания сайта-визитки на PHP" тому подтверждение. В поисках истины, я попытался расставить все по местам… перечитал некоторую литературу и статьи по паттернам проектирования и написал дополнение к упомянутой статье. Но решил запостить это дополнение, как отдельный топик в надежде на фидбэк. Под катом вы найдете несколько часто встречающихся схем MVC и MVP с описанием жизненного цикла приложения, а также описание менее популярных паттернов HMVC и MVVM. Разумеется, некоторые из перечисленных паттернов применимы не только к веб-приложениям, но в статье они рассматриваются именно в этом контексте.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

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

Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.

Кеширование – одна из многих тем, наряду с безопасностью и логированием, о которых знают и говорят все, но мало кто может это сделать правильно.

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

Когда-то я собрала набор простых правил, которые помогают избежать 80% самых распространенных ошибок, касающихся построения интерфейсов. Решила расшарить их для хабрасообщества.
Кому интересно — добро пожаловать под кат.

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Цель данной статьи — познакомить читателей хабра с NoSQL-СУБД MarkLogic (ML). Беглый поиск показывает, что в среде русскоговорящих айтишников она малоизвестна. Данным обзором я попытаюсь исправить эту ситуацию.

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

Это статья об изменениях, которые произошли в мире веб-разработки. Я наблюдаю огромное количество веб-разработчиков, которые буквально застряли в устаревших технологиях, особенно в мире .NET. Если вы еще не начали совершенствовать свои навыки, и адаптироваться к изменяющимся трендам, вы должны начинать уже сегодня.

За те 9 лет, что я занимаюсь программированием, в мою асю пришло несколько сотен просьб о помощи, от менее опытных, начинающих программистов. И вот, когда сегодня, в очередной раз, незнакомый человек попросил помочь ему написать плагин для вордпресс (код которого, честно говоря, я в глаза ни разу не видел), я решил написать небольшой гайд, который бы помог начинающим программистам правильно обращаться за советом к более опытным.