В повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

Итак, после моей предыдущей статьи я понял что тема про программирование драйверов Windows интересна хабровчанам, поэтому продолжу. В этой статье я решил разобрать простую программу-драйвер, которая делает только то, что пишет отладочное сообщение «Hello world!» при старте драйвера и «Goodbye!» при завершении, а также опишу те средства разработки, которые нам понадобятся для того, чтобы собрать и запустить драйвер.

Навеяно предыдущей статьей на эту тему.
Для того чтобы, структурировать свое понимание – что представляют собой threads (это слово переводят на русский язык как «нити» почти везде, кроме книг по Win32 API, где его переводят как «потоки») и чем они отличаются от процессов, можно воспользоваться следующими двумя определениями:

• Thread – это виртуальный процессор, имеющий свой собственный набор регистров, аналогичных регистрам настоящего центрального процессора. Один из наиважнейших регистров у виртуального процессора, как и у реального – это индивидуальный указатель на текущую инструкцию (например, индивидуальный регистр EIP на процессорах семейства x86),
• Процесс – это в первую очередь адресное пространство. В современной архитектуре создаваемое ядром ОС посредством манипуляции страничными таблицами. И уже во вторую очередь на процесс следует смотреть как на точку привязки «ресурсов» в ОC. Если мы разбираем такой аспект, как многозадачность для того, чтобы понять суть threads, то нам не нужно в этот момент думать о «ресурсах» ОС типа файлов и к чему они привязаны.

Очень важно понять, что thread – это концептуально именно виртуальный процессор и когда мы пишем реализацию threads в ядре ОС или в user-level библиотеке, то мы решаем именно задачу «размножения» центрального процессора во многих виртуальных экземплярах, которые логически или даже физически (на SMP, SMT и multi-core CPU платформах) работают параллельно друг с другом.

Суть многопоточности (для приложения) состоит в том, что процесс может состоять из нескольких (однотипных) потоков, выполняющихся «параллельно», то есть без упорядочивания по времени — выполнился один, пошел следующий. Использование многопоточности позволяет ускорить выполнение задачи и/или снизить нагрузку, таким образом, улучшая быстродействие самого приложения.

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

Я рассмотрю простой пример, как можно достичь эмуляции многопоточности в PHP.

Хотите стать обладателем гаджета, которого больше ни у кого нет? — Сделайте его своими руками
Если Вы знаете, с какой стороны надо браться за паяльник, то достаточно купить 4 сверхъярких белых светодиода, кусок макетки и порыться в своей коробке с хламом — и у вас есть все необходимое для создания оригинального светильника.

Некоторое время назад я опубликовал этот опус в своем блоге. Сейчас наступает пора очередного переезда и я, перечитывая собственные записи трехмесячной давности, решил поделиться таковыми с сообществом. Поскольку подходящего блога не нашлось, сначала опубликовал в личный, а теперь решил создать коллективный блог, посвященный инфраструктурным вопросам, в который и переношу эту запись.Итак, получилось так, что компании, в которой я тружусь пианистом, пришлось переехать — чуть раньше назначенного времени и чуть не туда, куда планировалось =) Собственно, сам по себе переезд относительно небольшой (50 мест) сети — невеликая проблема, но в данном случае все осложнялось рядом факторов:

1. До последнего момента никто не знал, куда-таки мы едем
2. Времени, как следствие из (1), было катастрофически мало
3. Под переезд были запланированы мероприятия по полной замене парка сетевого оборудования и телефонной станции (точнее, до этого собственной телефонной станции у нас просто не было:))

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

Должен заметить, что пять или шесть просмотренных офисов были близки к тому, что мы были готовы в них заехать, но основным препятствием было то, что там совершенно по-идиотски была реализована СКС. К сожалению, проектировщики (даже в очень навороченных бизнес-центрах) думают, по всей видимости, задницей — иначе, как объяснить, что на 600 квадратных метров офиса предусмотрено всего 30 мест СКС по два порта? Но это лирика, впрочем…

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

Знали ли разработчики LiveScript из Netscape о том, какое влияние окажет их язык, позже переименованный в JavaScript, на лицо интернета — веб-сайты, или, может быть, они твердо на это рассчитывали, но факт остается фактом — JavaScript на сегодняшний день является одним из самых важных и распространенных языков в мире.

В то время, как на стороне сервера трудится разношерстная компания языков в лице php, perl, python, ruby, .net, java и многих других, на стороне клиента JavaScript существует буквально в гордом одиночестве. Фактически, из маленького дополнения к html, JavaScript превратился в полноправного члена банды «html+css+js», который, зачастую, уже командует остальными, сверкая золотым браслетом с надписью «ajax» и делая недовольное лицо $( ) при случае.

Заранее предупреждаю и извиняюсь, но оно того стоит: букаф многа.

Введение

В средней школе я был «круглым» двоечником, которого переводили в следующий класс только под значительным влиянием моего отца, в то время проректора ФПИ, довольно влиятельного (в личном общении) и властного человека.

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

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

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

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

Здесь представлены

Пост тем, кто хочет немножко отвлечься от работы и поразвлекаться с умом.

Сегодня наткнулся на интересный проект: contextfree

Все помнят курс теории компиляторов с университета? contextfree — генератор изображений на основе контекстно-свободных грамматик. Терминалами выступают простые графические примитивы (CIRCLE, SQUARE, TRIANGLE и т.д.). Нетерминалы задаем мы. Правила вывода могут включать в себя так называемые преобразования (повернуть, отразить, сдвинуть, поменять цвет). На основе этой простой модели можно получать очень интересные вещи… буквально несколькими строчками кода.

Начнем с простого примера:
startshape JustASquare //Начальный символ грамматики

background { b -1 } //Здесь мы задаем фон. b -1 - означает преобразование
//По умолчанию фон белый (brightness = 1), мы изменяем brightness до 0.

rule JustASquare { // Здесь мы задаем простое правило.
SQUARE { b 1 r 45 } // Белый квадрат, повернутый на 45 градусов.
}



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

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



И вот стало известно, что на борьбу с «чумой 21 века», то есть с информационной перегрузкой, поднялись крупнейшие IT-корпорации мира. Microsoft, Intel, Google, IBM и другие компании на прошлой неделе договорились создать некоммерческую рабочую группу Information Overload Research Group, которая займётся выработкой психологических и технологических рекомендаций для помощи офисным работникам.

Конечно, есть определённая ирония в том, что борьбу с проблемой решили вести именно те компании, которые эту проблему и создали.

Эту статью я не хочу писать в стиле «10 правил» для работы с вредными клиентами. Хочу описать возможные ситуации при работе с «ненормальными» клиентами и как правильно с ними бороться (по моему мнению). Также в комментах буду рад услышать ваши дополнительные предложения по стратегии поведения в таких ситуациях.

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

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

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

Для начала, я сразу оговорю две вещи: во-первых, ни в коем случае не думайте, что я собираюсь «наехать» на rumkin’а — автора статьи. Статья очень хорошая, качественная, и я был бы рад, если б на Хабре статей такого уровня было как можно больше. Просто у меня возникли некоторые разногласия с автором, и я хотел бы поделиться ими с вами.
Во-вторых, я не профессиональный дизайнер/верстальщик, и на звание оного претендовать не хочу. Тем не менее, у меня есть интерес,, и вкус.
Можно сказать, что я просто ценитель и любитель этих искусств, по этому всё, что я буду писать дальше, основано на моих личных вкусах и пониманиях, нежели на богатом профессиональном опыте.

Теперь, когда вышесказанное вам известно,

Многоточие (эллипсис, от греч. ellipsis — незаполненность) — самостоятельный типографский знак, разновидность отточия, состоящий из трёх точек идущих подряд, используется для обозначения скрытого смысла, особенностей устной речи (вздох, пауза, задумчивость), недосказанности либо для исключения из текста некоторых слов, например при цитировании.

В данный блог обычно пишут статьи, где Linux представляется user-friendly, ниже приведенный текст скорее относится к разделу «Linux не для всех» и будет интересен гораздо более узкому кругу хабрачитателей.

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

Рассмотрим схему, с помощью которой можно смоделировать влияние различных параметров сети передачи данных на исследуемое приложение. Для моделирование очень удобно использовать операционную систему GNU/Linux, в которой существуют все необходимые инструменты.

Методы выработки коллективных решений

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

Вопрос: «Что быстрее — echo или print?» не перестаёт будоражить умы тех, кто считает себя профессиональным программистом на PHP. Руководство пользователя осторожно упоминает об имеющемся различии, но отсылает к статье стороннего авторства; та, в свою очередь, утверждает, что echo быстрее, но не приводит доказательств; трудно найти объективное сравнение, и всё это придаёт проблеме некий мистический ореол, на что клюют многие и многие.

Так не будем же оставаться в стороне и постараемся раз и навсегда разгадать эту загадку!

Flowplayer — Бесплатный видео-плеер для веба
FlowPlayer — это Flash медиа плеер. Вы можете использовать его нв ваших HTML страницах чтобы воспроизводить видео файлы. «Это ваш персональный YouTube».

Всем доброго времени суток.

Перевод заметки "40 Tips for optimizing your php code". Автор — Reinhold Weber.

1. Если метод может быть статическим, объявляйте его статическим.
2. echo быстрее, чем print.
3. Передавайте в echo несколько параметров, вместо того, чтобы использовать конкатенацию строк.
4. Устанавливайте максимальное количество проходов ваших циклов for до цикла, а не во время его выполнения.
5. Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы.
6. Остерегайтесь магических методов, таких как __set, __get, __autoload.
7. require_once дорого обходится.
8. Указывайте полные пути в конструкциях include/require, меньше времени будет тратится на поиск файла.
9. Если вам необходимо определить время, когда скрипт был запущен, используйте $_SERVER[’REQUEST_TIME’] вместо time().
10. Старайтесь использовать strncasecmp, strpbrk и stripos вместо регулярных выражений.