Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

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

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

Не-не, сказал, тесть, все не так. Если люди чего-то не делают, для этого может быть 4 причины. После чего мой арсенал управленческих инструментов пополнился еще одним. И именно об этом инструменте мы сегодня поговорим, а заодно разберем несколько историй из реальной жизни:

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

Искал я на просторах Интернета всего лишь скрипт для создания индекса изображений с lightbox и генерированием thumbnails. Помимо того что меня полностью устроило (phppi), нашел довольно интересную подборку галерей. В наличии комментарии и пояснения, думаю будет полезно новичкам да и бывалым время сэкономит.

Fullscreen Gallery with Thumbnail Flip

Сегодня речь пойдёт об WaterSpout — веб сервере, способном обрабатывать websockets запросы, позволяя общаться в реальном времени между сервером и браузером используя websockets или long polling. Написан он на PHP.

В первую очередь идёт проверка поддерживаются ли websockets (это Chrome, Опера и FF, если включим), если нет, то ничего страшного, будет использоваться long polling.
Преимущества этой технологии: доставка сообщений мгновенна, высокая производительность. Тестировал в Chrome, FF, IE6+.
Демка.

Прочитав недавно нововведения PHP 5.3, я обратил внимание на несколько интересных особенностей, скомпоновав которые можно получить реализацию шаблона проектирования Observer, гораздо красивее, чем имеющиеся в pear и symfony, причём вся реализация займёт всего несколько строк кода.

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

Статья может помочь вашему живому проекту не тормозить(или тормозить меньше), либо стать отправной точкой для исследования стороннего продукта.
Например, у вас стоит задача понять что же происходит внутри «Самописная система 3.14» и, опять же, помочь ей не есть по 100 мегабайт RAM на одного клиента.

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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

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

В MySQL есть очень полезная функциональность — кеш запросов. Кеш запросов доступен в MySQL начиная с версии 4.0.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

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

Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.

По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.

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

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

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

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

На Хабре некоторое время назад спрашивали про курсы по оптимизации MySQL. Мы разработали такой курс и проводим его дистанционно через интернет. Вот программа курса.

Курс продолжается 2 месяца (начать можно в любое время) и построен на выполнении практических заданий под руководством преподавателя. Все задания взяты из реальной практики, преподаватель ответит на все возникающие вопросы. Действует гарантия 100% возврата средств в течение первых двух недель по первому требованию.

Кризис не самое оптимальное время, чтобы пиарить новую услугу, но это оптимальное время для получения новых знаний. Получить знания можно не только на нашем курсе, но и используя открытые источники:
I. Видеозаписи докладов на Highload++:

• Петр Зайцев, «Масштабирование InnoDB»
• Константин Осипов, «Масштабирование СУБД MySQL на системах с многоядерной архитектурой»,
• Ваш покорный слуга, «Архитектура MySQL Cluster»
• Василий Степанов, мастер-класс «Оптимизация работы с MySQL»

II. Статьи по оптимизации MySQL на webew.ru
III. Задать интересующий вопрос на форуме SQLinfo.ru

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

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

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Триггер — это хранимая процедура, которая не вызывается непосредственно, а исполняется при наступлении определенного события ( вставка, удаление, обновление строки ).
Поддержка триггеров в MySQL началась с версии 5.0.2

С выхода в свет последней версии Zend прошло уже немало времени, а на Хабре регулярно проскакивали дискуссии о том, что же лучше — Zend for Eclipse или Eclipse PDT, в которых я неизменно принимал участие. Нынче я позволю себе потревожить публику своим взглядом на предмет, расскажу про всяческие плагины и вы сами сможете решить, что вам нужнее.