Вчера Marcel Pociot представил новое расширение для браузера Chrome «Laravel TestTools», которое позволяет «записывать» действия пользователя при создании тестов для Laravel.

Вот как это выглядит:

Начало

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

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

Сравнение старого магазина с новым

Google's beacon platform — это решение для работы с Bluetooth маячками. Платформа работает с разными маячками от разных производителей, предоставляя разработчикам единый, простой и гибкий инструмент.

Перед прочтением этой статьи я рекомендую ознакомиться с концепцией Physical Web о которой я рассказывал в своей прошлой статье: Концепция Physical web. Bluetooth маячки. Сравнение стандартов iBeacon, AltBeacon и Eddystone.

Google's beacon platform. Часть 1 — Proximity beacon API
Google's beacon platform. Часть 2 — Nearby meassages API

Основным средством, в рамках Google's beacon platform, для работы на клиентской стороне с bluetooth маячками, является Nearby Messages API. В этой статье я расскажу как настроить проекты на а платформах Android и iOS, и добавить в приложение возможность получать и разбирать сообщения от ble-маячков.

Вот весь код: var x = []; x[0x7fffffff]=1; JSON.stringify(x);

Для желающих попробовать: jsfiddle

Таким незамысловатым способом, можно намертво повесить firefox, довести до падения вкладку хрома и повесить основной поток nodejs.

Самое примечательное в этом то, что зависание происходит на уровне нативного кода функции JSON.stringify, что не позволяет прервать выполнение в том же firefox'е, как это обычно бывает при простом while(true);.

При выполнении внутри WebWorker'а в chrome, страница продолжает отвечать, но terminate не может завершить поток.

Так же по понятным причинам, такой код не обнаруживается jslint'ом.

«Project Comet» доступен для скачивания всем на сайте Adobe под названием Experience Design CC (Preview) v. 0.5. Пока только версия под OS X.

По функциональности не дотягивает до Sketch, но в перспективе думаю допилят и выпустят Windows версию.

Мне кажется у Sketch и XD будет судьба как у Textmate и Sublime. То есть первый был только под мак и остался в истории, а второй был набит всеми фичами первого и вышел кроссплатформенным, завоевав всеобщую популярность. Время покажет.

В прошлый раз я описал функционал плагина Semantic MediaWiki, позволяющего управлять структурированными данными в вашей системе и создавать на их основе различные представления. Ложкой дёгтя здесь является то, что пользователям приходится учить дополнительные элементы разметки.
Сегодня мы поговорим про расширение Semantic Forms, позволяющее сделать вики совсем не похожей на вики и привлечь к работе более широкий круг пользователей.



Напомню, что сердцем Semantic MediaWiki является механизм семантических свойств. Назначение семантического свойства странице хоть и похоже на простое создание вики-ссылки [[имя свойства::значение свойства | что выводить на экран]], но, всё-таки, это новый синтаксис. Вдобавок даже если наши пользователи будут настолько дисциплинированы, что прочитают и вникнут в руководство по созданию свойств, они вряд ли будут называть все термины единообразно.
На моей вики, посвященной историческим личностям половина людей будет описана свойством время рождения, другие участники опишут людей свойством год рождения, а третьи дата рождения. Теперь для того, чтобы получить список исторических личностей и вывести их даты рождения, мне нужно написать три запроса вместо одного:

{{#ask:[[Категория Историческая личность]] | ?Время рождения }}
{{#ask:[[Категория Историческая личность]] | ?Год рождения }}
{{#ask:[[Категория Историческая личность]] | ?Дата рождения }}

Для решения этих проблем применяют шаблоны и формы.

В своей предыдущей статье по оптимизации сайта на WordPress я рассказал об очень эффективном подходе к оптимизации за счёт кэширования страниц. В результате чего для незалогиненных пользователей время ожидания страницы клиентом (исключая время на установление TLS-сессии) сократилось с 820 мс до 30 мс (этот и все последующие замеры проводились с сервера, расположенного в том же городе, что и мой VDS), что, согласитесь, является отличным показателем. Однако, для залогиненных пользователей генерация страницы происходила по-прежнему долго — в среднем 770 мс на сервере. В этой части я расскажу о том, как я сократил это время до 65 мс, при этом полностью сохранив работоспособность пользовательского функционала.

Целью этой и предыдущей статей является моё желание показать возможность оптимизации сайтов не только на WordPress, а вообще любого веб-приложения. Поэтому я использую такое количество инструментов, и так детально разбираю их конфигурацию. Если же Вам просто нужно ускорить WordPress — установите плагин WP Super Cache. Если Вас, как и меня, интересуют технологии, позволяющие оптимизировать любой сайт, а также Вам интересно, что стоит учитывать при разработке веб-приложений, рассчитанных на высокие нагрузки — прошу под кат, но только после прочтения первой части — дорабатывать я буду ту же систему.

Недавно стало известно, что в наборе системных файлов Windows 10 Insider Preview Build 14251 содержатся два драйвера с названиями LXss.sys и LXCore.sys, которые могут иметь прямое отношение к реализации подсистемы Linux на Windows 10, для поддержки в последней запуска соответствующих приложений. Указанные названия файлов могут интерпретироваться как Linux Subsystem и Linux Core. Также эти два файла имеют отношение к Windows 10 Mobile, для которой Microsoft собиралась включить поддержку приложений ОС Android, также основанной на ядре Linux.



Кроме этого, известный гуру внутреннего устройства Windows и один из соавторов известной книги Windows Internals, Alex Ionescu, показал в своем твиттере скриншот одной из функций драйвера LXCore.sys Windows 10 того же выпуска в отладчике Windbg, на котором виден анализатор заголовков 64-битных исполняемых файлов Linux, известных как ELF64.

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

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

Помимо вполне понятной официальной документации (Chromium Wiki), существуют и статьи о том, как получить исходный код и собрать проект Chromium (например).

Я же хотел рассказать о том, как на основе этого кода можно создавать приложения на C++, способные компилироваться и выполняться на нескольких операционных системах и архитектурах. Конечно, для этой цели уже существуют библиотеки, такие как Qt и boost. Но именно поэтому данная статья относится к разделу 'ненормальное программирование', ведь никто всерьез не рассматривает код Chromium как основу для кроссплатформенного приложения.

Наш чат устарел: за несколько лет эволюции он превратился в громоздкий View Controller со странными исправлениями, в которых никто не мог разобраться. Стало трудно добавлять новые типы сообщений, зато с легкостью появлялись новые баги. Поэтому мы решили переписать чат на Swift с чистого листа и выложить его в open source.
Мы начали работу над проектом, поставив перед собой две цели:

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

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

Привет, Хабр! Кажется, иногда могут быть посты-исключения, а не только посты с кусками кода? Сегодня в блоге у нас именно тот случай. Посмотрите наше небольшое видео (кстати, код есть на 3-й секунде). Не забудьте поздравить маму с 8 марта и сказать ей «спасибо»!

Введение

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

Возможно, по заголовку кому-то покажется, что это жалобный пост, который говорит о том, как плохо живётся неквалифицированному школьнику, который похватал всего из разных статей в интернете. Нет, пост не жалобный, мы говорим про full stack, а не full slack, и в конце будет так же рассмотрен список плюсов. И мы будем рассматривать не школьника, а разработчика с опытом работы в пять и более лет. Просто посмотрим, какие минусы есть в таком развитии.

Последние несколько лет я занимаюсь R&D в области интернета вещей и распределенных систем, а так же являюсь Google developer expert IoT. В этой статье я хочу поделиться своим опытом и рассказать про новую концепцию Physical Web. Так же расскажу про разные маячки (англ. Beacon — маяк) и сравню основные стандарты iBeacon, Altbeacon и Eddystone.

Привет! Я руковожу небольшим ИТ-аутсорсингом, и к нам в прошлом году обратилось сразу несколько клиентов с похожими задачами — сделать так, чтобы никто не узнал, где именно стоят сервера компании.

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

Мы придумали вот такую схему:



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

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

Итак, продолжаем разбор типичных заблуждений о MySQL в рамках культурного обмена и осеннего обострения. Для начала несколько критических отзывов о первой части.

Привет, Хабр! В этот прекрасный пятничный день предлагаем вам ознакомиться с очередной частью цикла переводов советов для веб-разработчиков. Предыдущие части: 1-16, 17-32, 33-48.

Содержание:

   49   Циклическое переключение между панелями при помощи шорткатов
   50   Проверка и активация CSS media queries, а также нахождение этих правил в коде
   51   Предустановка разрешения нового устройства
   52   Улучшения полоски хлебных крошек в панели Elements
   53   Печать стектрейса в консоли
   54   Детектирование долгих фреймов (не путать с iframe)
   55   Продвинутая фильтрация запросов в панели «Network»
   56   Поиск по проекту с возможностью указания файла
   57   Новый экспериментальный редактор раскладки страницы
   58   Дублирование DOM-элементов
   59   Просмотр скриншотов поведения страницы
   60   Редактирование html-кода в панели «Console»
   61   Простые клавиатурные трюки для управления панелей «Стили»
   62   Выбор цвета, сгенерированного палитрой
   63   Инкремент и декремент чисел в DOM-атрибутах
   64   Сетевые запросы в панели «Timeline»

Здравствуйте, уважаемые читатели.

Нас заинтересовала книга "Node.js Design Patterns", собравшая за год существования очень положительные отзывы, небанальная и содержательная.



Учитывая, что на российском рынке книги по Node.js можно буквально пересчитать по пальцам, предлагаем ознакомиться со статьей автора этой книги. В ней господин Кассиаро делает очень информативный экскурс в свою работу, а также объясняет тонкости самого феномена «паттерн» на материале Node.js.

Поучаствуйте, пожалуйста, в опросе.

Вот вы там все сидите и ничего не знаете, а мы, тем временем, пилим помаленьку мега-релиз поискового движка Sphinx за номером 3.0. Грядет ряд больших переделок. Часть из них, как полагается, ещё даже как следует не начата. Однако большая часть уже скорее готова, чем нет. А отдельно взятые изменения даже протекли в публичную ветку 2.3. Так что, пожалуй, настало время вкратце начинать рассказывать, чего ожидать в светлом будущем: надеюсь, не столь отдалённом. Кому интересно почитать, все под кат; кому послушать, приходите на meetup в эту субботу. Если совсем вкратце, то: прощай, концепция дополняющего основную базу движка; привет, хранилище документов, тотальный RT, репликация, REST и ряд других известных ключевых слов.

Кевин Поулсен, редактор журнала WIRED, а в детстве blackhat хакер Dark Dante, написал книгу про «одного своего знакомого».

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

Квест по переводу книги начался летом в ИТшном лагере для старшеклассников — «Шкворень: школьники переводят книгу про хакеров», затем к переводу подключились и Хабраюзеры и даже немного редакция.

(Долгожданный перевод 20-й главы)

Глава 20. «The Starlight Room»

(за перевод спасибо Artem Nedrya aka Translation Designer )

С потолка, прямо над роскошными диванами клуба «Starlight Room», владельцем которого был Гарри Дентон, свисали девять винтажных люстр; лучи стокилограммового зеркального шара бегали по поверхности танцплощадки. Огромные тёмно-красные шторы свисали по обе стороны широких панорамных окон, словно сценические занавеси, за которыми было видно огни небоскрёбов Сан-Франциско.

Расположенный на двадцать первом этаже отеля «Sir Francis Drake», клуб «Starlight Room» был одним из самых дорогих ночных клубов этого города и неотъемлемой частью его бурной ночной жизни с интерьером в стиле 1930-х годов, отделанным тёмно-красной дамастовой тканью и шёлком ручной выделки. Скорее кричащему, чем стильному клубу, удавалось привлекать клиентов только благодаря регулярным тематическим вечерам. В ту среду клуб организовывал «Русскую вечеринку», поэтому кругом гремела музыка с Родины, а официанты в смокингах разливали водку столпившимся возле стойки бара посетителям.

В женском туалете кто-то целовал Тсенгельтсетсег Тсетсендельгер. Уже успев выпить в тот вечер, молодая монгольская иммигрантка не помнила, как так случилось, или зачем, что длинноногая брюнетка захотела её поцеловать. Спустя мгновение глаза Тсенгельтсетсег округлились от удивления. Рядом стояла ещё одна брюнетка, точная копия первой.

Мишель и Лиз представились, и на лице Тсенгельтсетсег появилась широкая, непритворная улыбка. Она сказала близняшкам Эскере, что они могут звать её просто «Ти», по первой букве её фамилии.

Ти регулярно посещала русские вечеринки в этом клубе и без проблем изъяснялась на русском и английском. Родом из северной части Монголии, она ещё застала времена, когда страна находилась под влиянием Советского Союза. Русский она учила в школе до тех пор, пока Советская империя не распалась и монгольский премьер-министр не объявил английский язык вторым официальным языком — и это в стране, не имеющей выхода к морю…