Вроде простой вопрос, даже не понятно что на него ответить, правда?
Мы все знаем как создать переменную, как получить значение переменной, как взять ссылку на переменную в конце концов.
Но как они работают изнутри?
Что происходит в интерпретаторе, когда вы изменяете значение переменной? Или когда удаляете ее?
Как реализованы типы переменных?

В этой статье я постараюсь раскрыть именно эти темы.

Abstract

Переменные в PHP выражены в виде неких контейнеров, которые хранят в себе тип переменной, значение, кол-во ссылающихся переменных на этот контейнер, и флаг — является ли эта переменная ссылочной.

В этой статье я расскажу, какие проблемы прийдется решить, чтобы получить VPS с реально работающим node.js сервисом. Это все элементарные вещи, но, может быть, кому-нибудь еще пригодится.

Установка node

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

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

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

Но обо всём по порядку.

Данная статья является логическим продолжением следующих статей:

• Работа с памятью (и всё же она есть)
• Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

Очевидно, что и формулирование проблем и поиск технических решений будет проходить легче и эффективнее, если обе стороны — бизнес и разработка, будут вовлечены в этот процесс.

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

На конференции HotDep 2012 Джерард Хольцман из Лаборатории реактивного движения НАСА прочёл лекцию о том, как обеспечивалась надёжность и корректность кода для марсохода Curiosity. Часовая лекция рассказывает, какие методики, стандарты кодирования и инструменты разработки применялись программистами НАСА, чтобы написать три с половиной миллиона строк сверхнадёжного кода, который в автономном режиме посадил Curiosity на поверхность Марса и обеспечивает работу всех его систем и приборов.

Лекцию можно посмотреть онлайн на сайте usenix.org, или скачать в формате .mp4 (228 Мб).

С первого дня пользования меня очень интересовал вопрос — как же на обычном емкостном экране, которые воспринимает только определенную площадь прикосновения удалось добиться работы тонкого стилуса, да еще с кнопкой и несколькими степенями нажатия?

В этой статье я попытаюсь ответить на этот вопрос, рассказав немного об интересных технических решениях, примененных в этом телефоне.

Вот есть в России VK и Яндекс. Всё у них замечательно, молодцы вообще ребята: и предельно высокая посещаемость, и сложность инфраструктуры, и применяемые технологии, но в мире они не столь популярны. Вот и Китай у большинства любителей, из тех, чей взгляд устремлен в Калифорнию, где каждые 3 месяца появляется hitech-компания в миллиард долларов, в картине мира просто отсутствует. Эта страна во многих вопросах, где дело касается количества, необычная, постоянно ведь на слуху города Китая, метро, мосты, порты; так вот я тут — о массивных китайских сайтах. Сравнивать с DDOS как атакой глупо, та совсем разная и она не обыденность, но есть сайты где инфраструктура заточена для миллионов, хотя бы только поэтому они показались мне интересными.

Этой весной, Питер Тиль (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: Стагнация или сингулярность?

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

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

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

Случилось! Мы готовы презентовать долгожданное приложение для Android. Пока его видели всего 200 человек — журналисты, участники бета-тестирования, команда проекта. Наступило время официального релиза!

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



UPD: Ура, мы выпустили новую версию! Теперь приложение можно перенести на карту памяти и оно занимает меньше места.

После очередной порции прочитанных статей на силиконрус, посещения Startup Weekend и конференции IDCEE решил задать вполне простой вопрос, который меня все время мучает: а что такое стартап?

Как бы странно не звучало, но каждый понимает это понятие по разному. С одной стороны, стартап уже давно превратился в баззворд, но, с другой стороны, без понимания смысла понятия, наверняка, сложно найти общий язык с инвесторами, коллегами.

Скажу сразу — я не знаю точное определение слова “стартап”, но попытаюсь порассуждать на тему, что точно стартапом не является, а там — где-то в конце статьи может и найдем заветную формулу стартапа.

Начну, пожалуй, из стандартных ответов на вопрос “что такое стартап”. Сразу отмечу, что эти ответы говорили не школьники, а вполне приличные и умные люди, связанные с этими же стартапами.

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

Введение

Описано было довольно хорошо вот здесь.

Как его подключить

Если у Вас версия 22 и выше — он у Вас уже установлен. Если нет — установите новую версию. :)

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

Хочу поделиться опытом миграции боевой базы данных с MySQL 5.0 на Percona Server 5.5 под нагрузкой почти без отрыва от производства.

Опишу вкратце эволюцию нашей базы до текущего состояния

База у нас древняя, пережила несколько апгрейдов MySQL. Начинали с MySQL 3.x. С ростом нагрузки, уже на MySQL 5.0, настроили репликацию и подключили еще один сервер для чтения. Тогда мы это делали стандартными средствами MySQL, без привлечения xtrabackup — полностью блокировали сервер на время создания мастер-дампа и вывешивали на сайтах заглушки.

Затем встала следующая проблема — на томе с данными стало заканчиваться место. Плюс InnoDB-хранилище исторически располагалось в одном файле. Было рассмотрено много вариантов решения. Начиная от размещения базы на iSCSI-томе и заканчивая перетыканием в рейд более емких дисков, расширением на них volume group / logical volume с последующим расширением файловой системы.

В качестве временного варианта решили подключить iSCSI-том из виртуалки под VMWare vCloud (не реклама, честно!). vCloud стоит у нас под боком.

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

Проблема

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

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

А вот с пользователями без флеша (8-10% от дневной аудитории) было сложнее. Мы предлагали им загружать файлы через обычную форму с />. Файлы из неё отправлялись через iframe вместе с содержимым самого письма, и это занимало много времени. Нажав кнопку «Отправить», пользователь долго ждал, пока загрузятся файлы.

Что такое SugarJS?

SugarJS — это open source (лицензия — MIT) библиотека Javascript, который расширяет нативные объекты полезными методами. Она разработана, чтобы быть интуитивным, ненавязчивым инструментом, повышающим выразительность кода, который позволял бы делать больше с меньшим количеством кода и меньше задумываясь над рутиной.

На самом деле у них очень информативный и простой сайт — где все уже хорошо написано.
Я просто постараюсь обозначить основные моменты.

Кратко...

• Расширяет нативные элементы Javascript полезными, интуитивными методами.
• Прост для понимания и в использовании.
• Метод SugarJS не используется при наличии метода в родной реализации браузера.
• Имеет систему тестирования, имеющую огромный набор тестов.
• Расширяет возможности работы с датой и временем, обеспечивает их форматирование на нескольких языках (русский есть).
• Отлично ладит с другими фреймворками и сторонним кодом.
• Модульность, вы можете включать только нужные пакеты.
• Полностью совместимый ECMAScript.
• Заявлена поддержка всех основных браузеров, включая мобильные.
• Поддерживает Node.js.
• Имеет хорошую и удобную документацию.

Заинтересовало? Добро пожаловать под кат.

Microsoft представила язык программирования TypeScript, который является надмножеством JavaScript, поддерживает статическую типизацию, модули, определение классов и интерфейсов. TypeScript транслируется в чистый JS, исполняется в любых браузерах, в Node.js и т.д.

Транслятор TypeScript вышел под лицензией Apache 2.0, с исходниками на CodePlex. Microsoft предлагает плагины для Emacs, Sublime Text и Vim.

Сегодня в зарубежных блогах появилась занятная новость о необычном поведении браузеров: на днях Chris Coyier, автор сайта css-tricks.com показал, как классу можно дать больший приоритет, чем id. Нужно всего лишь применить к объекту 256 классов!

Какой человек не любит халявы? Практически все ее просто обожают, и я не исключение. Вдохновленный статьей «Взломать Wi-Fi за 10 часов» я достал из недр харда BT5, скачанный ранее, и записал его на болванку. Результат не заставил себя ждать, и первый пароль был получен на следующее утро. И понеслась…

Доброго дня.

Весной наконец-то дошли руки до ремонта в ванной комнате. При сборе требований к будущему функционалу родилась мысль, а не добавить ли в ванну возможность слушать музыку? Например, проигрывать медиаконтент с домашнего NAS. Сама идея «музыки в ванной» мне понравилась, и я пошел в гугл смотреть, какие решения существуют.

По итогам всего мероприятия решил поделиться информацией и результатами своего труда.