Аннотация

Второй части этой статьи не планировалось, но тема нашла отклик, так что можно продолжить.

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

При повседневном использовании средств статического анализа можно добиться не только заметного уменьшения количества ошибок, но и улучшения качества кода в целом — показать это на практике и есть цель данной статьи.

О том, что можно найти и исправить с минимальным вложением времени (и максимальной отдачей) я расскажу под катом.

Привет, Geektimes! Сегодня мы продолжаем наш цикл PC Buyers Guide и поговорим о той железке, без которой вообще ни один компьютер не будет работать. О блоке питания.



Вопросов про блоки питания задают много и регулярно. Разумеется, самый распространённый вопрос — о том, как правильно выбрать БП и насколько мощный «питальник» нужен для опреедлённого набора железа. Но кроме подсчётов необходимой мощности есть ещё несколько интересных тем, которые хотелось бы сегодня осветить: что такое сертификация «80+», какие маркетинговые «улучшайзеры» стоит проигнорировать, а какие учесть, ну и, разумеется, какого производителя выбрать.

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

• var id = setTimeout(fn, delay); — Создает простой таймер, который вызовет заданную функцию после заданной задержки. Функция возвращает уникальный ID, с помощью которого таймер может быть приостановлен.
• var id = setInterval(fn, delay); — Похоже на setTimeout, но непрерывно вызывает функцию с заданным интервалом (пока не будет остановлена).
• clearInterval(id);, clearTimeout(id); — Принимает таймер ID (возвращаемый одной из функций, описанных выше) и останавливает выполнение callback'a.

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

В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.

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

Почти каждому, у кого есть сервера с привязанными к ним доменами, так или иначе приходится решать вопрос с почтой, как минимум с доступностью адресов вида webmaster/postmaster/abuse@domain.
Кто-то учит M4 и настраивает встроенный sendmail, кто-то использует сторонние сервисы ( например от Google ), кто-то — поднимает стандартную связку postfix+courier-imap+mysql ( ну или аналоги ).

Мне первое было делать лениво, второе — не хотелось по идеологическим причинам, а третье — слишком избыточно. Поэтому я нашел свой «срединный путь», о чем и хочу рассказать в этой статье.

Prerequirements

При написании этого руководства я предполагал, что пользователь способен взаимодействовать с *nix-системами посредством консоли, умеет устанавливать пакеты своего дистрибутива и владеет как минимум одним текстовым редактором для редактирования конфигов. В качестве примера я буду устанавливать пакеты на Arch Linux, поскольку это мой домашний дистрибутив.

В конце 2008 года на тогда ещё небольшую петербуржскую компанию вышел один западный медиахолдинг примерно так:
— Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
— Да, только мы не…
— Да мне пофиг. Хотите заказ?

Проблема была в том, что видеомонтаж требовал адовой производительности, и тогда использовались RAID-5 массивы. Чем больше дисков в RAID-5 — тем выше была вероятность отказа прямо во время монтажа (для 12 дисков — 6%, а для 36 дисков — уже 17-18%). Дроп диска при монтаже недопустим: даже если диск падает в хайэндовой СХД, скорость резко деградирует. Медиахолдигу надоело с криком биться головой о стену каждый раз, и поэтому кто-то посоветовал им сумрачного русского гения.

Много позже, когда наши соотечественники подросли, возникла вторая интересная задача — Silent Data Corruption. Это такой тип ошибок хранения, когда на блине одновременно меняется и бит в основных данных, и контрольный бит. Если речь о видео или фотографии — в целом, никто даже не заметит. А если речь про медицинские данные, то это становится диагностической проблемой. Так появился специальный продукт под этот рынок.

Ниже — история того, что они делали, немного математики и результат — ОС для highload-СХД. Серьёзно, первая русская ОС, доведённая до ума и выпущенная. Хоть и для СХД.

Не кажется странным, что навязчивое гудение компьютера всеми воспринимается «как норма»? Можно вообразить весь ужас происшествия, если внезапно эти же звуки начнёт издавать любимый телевизор. Расценивать такое событие можно будет только как серьёзную поломку. Так почему компьютер не сделать, подобно телевизору, таким же уютно тихим?!

Итак, настала пора отступить от стереотипов и поменять хорошее на лучшее!

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

Цель статьи — поделиться исследовательским и практическим опытом в компоновке компьютера, который при работе не издавал бы ни единого звука.

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

Хотя на самом-то деле, если вспомнить историю Си, всё достаточно очевидно и, главное, логично. А все жалобы людей, «обжёгшихся» на неопределённом поведении для людей не забывших что такое Си и зачем он вообще существует звучат примерно как: «я тут гвозди бензопилой забивал… забивал и забивал, всё было хорошо, а потом я дёрнул за ручку и у неё коготки как забегают, задёргаются, мне руку оттяпало и полноги… ну кто так строит?».

Люди, которые знают что такое бензопила пытаются, конечно, объяснить, что за если за эту рукоятку дёрнуть, то так, в общем-то, и должно быть, но люди, считающие, что у них у руках такой себе молоток говорят «мимо» них, и, в результате, все остаются при своих.

Доброго времени суток, уважаемые хабравчане. Сегодня увидел статью на хабре «Официальный гайд по лучшим практикам в Symfony» и понял, что мне есть что исправить добавить. К вашему вниманию список личных советов и объяснение к ним.

Используйте по меньше аннотаций

Лично я люблю аннотации, но с опытом понял, что они приносят некий дискомфорт. Дело в том, что всю конфигурацию перенести в аннотации нельзя. Остается 2 варианта:

• Максимум в файлах конфигурации ( например yml);
• Немножко в файлы, немножко в аннотации.

Если выбрать второй вариант, то при росте проекта получается каша. И в вашем коде аннотаций больше, чем логики. Отговорки по типу «так легче находить роуты» не принимаются. Так как если расскидывать файлы конфигураций правильно, ты всегда знаешь, где находятся роуты к определённым контроллерам. Я уже молчу про команды в консоли, по типу route:debug, и отладчик, в котором видно название екшена и имя роута.

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

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

Под катом я выписал основные тезисы, большинство из них подробно аргументируется внутри книги, в некоторых «шокирующих» местах помимо тезиса есть небольшое объяснение.

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

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



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

Для разработчика обратная совместимость в первую очередь подразумевает, что единожды принятое обязательство предоставлять какую-либо функциональность невозможно отменить, исправить или перестать поддерживать.

Вездесущий… это определённо то слово, которым можно описать язык PHP по отношению к вебу. Он действительно вездесущ. В настоящее время, среди всех серверных языков программирования, PHP используется наиболее широко. На нём написаны более 80% сайтов, при этом следующий по популярности ASP.NET со своими 17% остаётся далеко позади.



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

Именно в этом и заключается основная проблема поиска высококвалифицированных PHP-разработчиков. Относительно низкий порог вхождения и 20 лет развития языка привели к тому, что PHP-программисты стали такими же вездесущими, как и сам PHP. Многие из них могут на законных основания утверждать, что «знают» язык. Однако разработчики, которые действительно являются экспертами по PHP, способны создавать куда более функциональное, надёжное, масштабируемое и простое в сопровождении программное обеспечение.

Как же отличить тех, кто обладает реальной компетентностью в PHP (не говоря уже о тех, кто входит в 1% наиболее опытных кандидатов) от тех, у кого только поверхностные знания?

Здравствуй Хабр!

Периодически возникает необходимость отследить запросы, которые отправляет Ваше приложение к базе данных. К примеру:
— Вам нужно отладить/доработать чужой код;
— Запросы генерируются с помощью сторонней библиотеки (к примеру ActiveRecord), не понятно, какие именно и сколько их;
— Нужно оптимизировать приложение: посмотреть какие запросы и сколько их, посмотреть explain этих запросов.

В этих ситуациях на помощь приходит Beaver mysql logger.

Одним замечательным летним вечером, я в пылу спора имел глупость заметить, что можно написать быстро работающее решето Эратосфена на CUDA. N = 1000000000 (девять нулей) как цель. And the legend has begun…

Не буду опускаться в подробности алгоритма, о нем можно почитать, например, тут и сразу покажу код, которым я располагал на тот момент:

#include <iostream>
#include <math.h>

using namespace std;

int main()
{
	double number = 1000000000;
	bool* a = new bool[int(number/2)];
	int i,j,result;

	for (i=0; i<number/2; i++)
		a[i] = true;

	for (i=3; i<=floor(sqrt(number)); i+=2)
		if (a[i/2])
			for (j=i*i; j<=number; j+=i*2)
				a[j/2]=false;

	result = 0;
	for (i=0; i<number/2; i++)
		if (a[i]) result++;

	cout << result << endl;

	delete[] a;

	return 0;
}

Однопоточный немного оптимизированный код, который работает на 14-15 секунд на Core i3 330M и затрачивает большое количество памяти. С него и начнем.

Сайт GameTutorials, известный своими уроками по C/C++/Win32/OpenGL/Direct3D/C#/Java, открыл все свои материалы для свободного изучения. Все уроки проверены на совместимость с Visual Studio 2013, в самом ближайшем будущем ожидаются уроки по Unreal Engine и Unity Engine, кроме того, будут обновлены устаревшие уроки по OpenGL и DirectX (сейчас на сайте описана версия DirectX 9).

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

Для просмотра и скачивания уроков потребуется зарегистрироваться.

Очень часто в интернете встречаюсь со статьями, в которых приводят кучу примеров с якобы странным поведением MySQL по сравнению с другими БД. Чтобы стало понятно, о чём я говорю, приведу несколько примеров:
1. Деление на ноль возвращает NULL вместо ошибки
2. Выход за диапазон допустимых значений неявно приводит число к допустимому значению, а не к ошибке и откату транзакции
3. Вставка неверного типа данных также приводит к неявному преобразованию и успешному выполнению операции
Таких примеров я могу привести огромное число, но цель статьи не сделать очередное собрание высосанных из пальца примеров, а объяснить, почему происходит то или иное действие. Вся эта мистика MySQL давно описана в документации и легко объяснима, в чём вы сможете убедиться сами, прочитав статью до конца.
Для меня эта первая статья на хабре, поэтому я старался писать дотошно подробно. Уверен, что она будет полезна всем, кто работает с MySQL. Большую помощь в написании статьи оказала подготовка к сдаче на сертификат разработчика MySQL, а точнее книга «MySQL Certification Study Guide».
Итак, мой друг, начнём!

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

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

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

Вопрос масштабирования ресурсов выделенных серверов сопряжен с целым рядом сложностей: добавление памяти или дисков невозможно без простоев, а апгрейд дисковой подсистемы зачастую предполагает полный перенос всех данных (объем которых может быть очень большим) со старого сервера на новый. Простое перемещение дисков из одного сервера в другой очень часто тоже оказывается невозможным: причиной этого может быть несовместимость интерфейсов, использование разных RAID-контроллеров, географическая удаленность серверов друг от друга и т.п. Копирование же данных по сети может занимать очень много времени, в течение которого сервис простаивает. Как можно перенести данные на новый сервер, минимизировав время простоя сервисов?

Мы долго думали над этим вопросом и сегодня представляем вниманию широкой аудитории решение, которое кажется нам наиболее удачным.