Данный пост является переводом не статьи, как принято, а доклада+презентации, поэтому текст поста достаточно вольный.

Думаю, всем хорошо известно и очевидно, что PHP — один из самых популярных языков программирования, на котором написано множество веб-проектов, начиная с персональных homepage-страниц и заканчивая мастодонтами типа Facebook, Vimeo, WordPress и даже YouPorn.

PHP появился в 1995 году, при этом полноценная поддержка ООП была реализована только в PHP5, который вышел в 2005 году. За это время было написано большое количество кода, как хорошего, так и плохого, а точнее сказать сильно устаревшего и тяжело сопровождаемого.

Многие проекты, как и экосистема PHP в целом, к настоящему моменту стали представлять подобие оживленного городского квартала.

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

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

Данная статья предназначена для разъяснения сути фундаментальных методов построения и оптимизации «искусственного интеллекта» для компьютерных игр (в основном антагонистических). На примере игры в зайца и волков будет рассмотрен алгоритм «Минимакс» и алгоритм его оптимизации «Альфа-бета отсечение». Помимо текстового описания, статья содержит иллюстрации, таблицы, исходники, и готовую кроссплатформенную игру с открытым кодом, в которой вы сможете посоревноваться с интеллектуальным агентом.

Для тех кто не в курсе, Knockout.js — это популярная JavaScript библиотека, позволяющая реализовать Model-View-View Model (MVVM) паттерн на клиенте. На Хабре уже много писали про него (раз, два, три, четыре, пять, видео). Освоить Knockout.js можно очень быстро — ведь есть система интерактивного обучения, куча живых примеров (можно потыкать и посмотреть исходный код) и прекрасная документация.

Очень часто Knockout.js используют в связке с ASP.NET MVC — ведь библиотека существенно упрощает написание клиентской логики. Однако, возникает много типичных проблем для клиент-серверной разработки: основную модель и часть логики её обработки приходится описывать как на клиенте (JavaScript), так и на сервере (C#/VB). Кроме того, есть рутинная часть, связанная с обращением клиента к серверным методам и передачи им модели для обработки. Но не стоит печалиться! Теперь у нас есть Knockout MVC — это .NET оболочка для Knockout.js, которая генерирует весь нужный JavaScript-код за нас. Нам остаётся только описать нашу модель на C# и в MVVM-стиле указать для каждого нужного html-элемента к какому свойству модели нужно привязаться (а можно указать и целые выражения — они будут транслированы в js). Таким образом, можно получить полноценное кроссбраузерное клиентское веб-приложение без единой строчки JavaScript!

Недавно (буквально два года назад) тут пробегала статья Только 10% программистов способны написать двоичный поиск. Двоичный поиск — это классический алгоритм поиска. Мало того, это еще чрезвычайно простой алгоритм, который можно очень легко описать: берем отсортированный массив, смотрим в середину, если не нашли там число, в зависимости от того, что в середине — ищем это число этим же методом либо в левой части, либо в правой, откидывая средний элемент. Для функций также, просто берем не массив, а функцию. Все очень и очень просто, алгоритм описан почти везде, все баги словлены и описаны.

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

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

Название сайта светить не буду — думаю, программисты сами узнают. Скажу лишь, что это приложение для социальной сети нагрузкой 70-150 тысяч посетителей в обычное время. Все усложняется тем, что периодически производится рекламная рассылка, которая привлекает около 200-300 тысяч посетителей за пару часов.

Итак, под катом описание всей борьбы на протяжении 4 дней.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

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

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Это не шутка. 90% от числа позвонивших в нашу компанию остаются с нами и пользуются услугами нашей компании как минимум еще один раз. Я решил не мудрить с теорией и изложить основное тезисами. Уверен, кому-нибудь пригодится. Наш бизнес — такси, однако большинство «ноу-хау» применимы совершенно в любом бизнесе.

Здравствуйте.

На написание статьи меня сподвигнул этот пост. В нём приведено описание инструментов и некоторая теоретическая информация.

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

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

Простота — дух эффективности. // A. Freeman

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

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

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

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

Привет, Хабрасообщество!
По следам недавно прошедшей конференции DevConf 2012 хочу поделиться записями из своего блокнота, которые показались лично мне наиболее интересными и полезными. Возможно, кому-то все это хорошо известно. Поскольку доклады шли одновременно в нескольких залах, то все их посетить было невозможно, поэтому ваши дополнения с удовольствием почитаю в комментариях.
Темы, которые прежде всего интересовали меня, это:
— развертывание системы и непрерывная интеграция (Continuous Integration)
— PHP 5.4, PHPUnit, Yii
— тестирование в javascript

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

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

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



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

Представьте двух героев: коммерсанта Александра и сисадмина Василия. Вася, как олицетворение среднестатистического клиента, каждый вечер заходит в магазин Саши (представителя розничной сети) и покупает пиво. Саша заказывает для него 7 бутылок пива в неделю. Иногда Вася остаётся работать с ночевкой и не выходит из серверной, а иногда – после работы берёт по две бутылки пива для себя и главбуха.


^{График спроса на пиво в зависимости от жизненных приключений Васи}

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

Введение и подготовка

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

Почему Java?

Ничего объективного я тут не скажу, а скажу лишь то, что я люблю этот язык, и мне нравиться писать на нем. Да, на Java нет игр AAA-класса, но Java предоставляет огромные возможности, больше кол-во встроенных средств и быстроту написания кода.

IDE

Начнем с выбора IDE. Я являюсь фанатом Eclipse и посоветую вам его.
Если же почему-то вам он не понравился, вы можете использовать NetBeans, Intellij IDEA или командную строку и ваш любимый редактор.

JDK

И скачаем JDK последней версии: JDK 7u4

Скорее всего проблем с установкой IDE у вас не возникнет, а если у вас 64-битная система, все же посоветую устанавливать 32-битный Eclipse, так как иногда бывают ошибки и Eclipse у вас просто не запустится.

Под катом мы приступим к созданию игры.

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

Поскольку разработка сайта — это командная, многоэтапная работа, то для достижения качественного результата на этапе дизайн-верстка, необходимо проработать не только визуальную часть дизайна, но и продумать интерактивные элементы. То есть те, которые изменяют свое состояние от действий пользователя. Это сразу откинет много вопросов верстальщика типа: «а как эта кнопка будет подсвечиваться?».