Привет, %username%! Бывает необходимо генерировать ID не подряд, причем чтобы они гарантированно не повторялись. На youtube это используется для того, чтобы вы не могли брутфорсом получить все новые и старые видосики, так же это не редкость на разных файлообменниках и вообще везде где нужно предотвратить или хотя бы затруднить возможность прямого перебора значений.


К примеру, в системе moodle, которая использовалась у нас в универе для тестирования студентов, ID ответов были инкрементными и сквозными на всю базу. Логично предположить, что правильным ответом был тот, что с наименьшим ID в пределах вопроса. В общем, проблем с тестами у нас не было. Потом они перешли на GUID, но я к тому моменту уже выпустился, хехе.

Давайте рассмотрим несколько способов генерации таких ограниченных по длине последовательностей от самых простых до криптографически стойких.

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

Как и раньше, библиотека OpenSource и распространяется по лицензии MIT, так что берите, используйте и, вообще, далайте что хотите без каких-либо ограничений.

Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «React Patterns» Майкла Чана, с некоторыми моими примечаниями и дополнениями.

Прежде всего хотел бы поблагодарить автора оригинального текста. В переводе я использовал понятие «Простой компонент» как обозначение Stateless Component aka Dump Component aka Component vs Container
Конструктивная критика, а так же альтернативные паттерны и фичи React приветствуются в комментах.

Оглавление

• Простые компоненты — Stateless function
• JSX распределение атрибутов — JSX Spread Attributes
• Деструктуризация аргументов — Destructuring Arguments
• Условный рендеринг — Conditional Rendering
• Типы потомков — Children Types
• Массив как потомок — Array as children
• Функция как потомок — Function as children
• Функция в render — Render callback
• Проход по потомкам — Children pass-through
• Перенаправление компонента — Proxy component
• Стилизация компонентов — Style component
• Переключатель событий — Event switch
• Компонент-макет — Layout component
• Компонент-контейнер — Container component
• Компоненты высшего порядка — Higher-order component

Поехали!

Здрасте!
Множество информации по SEO (оптимизация, продвижение, вот это вот все) разбросано по просторному интернету, создано множество статей и форумных топиков на эту тему. В данном посте, я собрал рекомендации и инструменты, которые касаются непосредственной страницы сайта (структура, код, вот это вот все).

В статье вы найдете:

• структурные элементы страницы: заголовки, картинки, URL, контент. Рекомендации по их использованию и оценки важности в ранжировании.
• микроразметка: кто она и с чем ее едят. Рассмотрены schema.org и OpenGraph
• дана оценка инструментам с точки зрения важности для ранжирования, usability или же поведенческих факторов
• на примере крупный процветающих сайтов рассмотрены примеры использования описанного инструментария

Статья носит образовательный характер, и поэтому даже если вы собаку съели в данной области, можете зайти и оставить свой профессиональный комментарий и оценку содержания поста.

Удостоверяющий центр «Let’s Encrypt» (далее просто letsencrypt) вышел из беты пару месяцев назад, пообтерся в реальных условиях, избавился от детских болезней и оброс различными клиентами. И к этому моменту выдал 5 миллионов сертификатов. Самое время внедрять, т.е. получать сертификаты на свои домены и обновлять их в автоматическом режиме. Но как внедрить так, чтобы приблизиться к любимому админскому «поставил и забыл»? Чтобы было просто получать новые сертификаты, а старые при этом обновлялись автоматом? Ну и как добавить немного безопасности в этот процесс?
Ответ под катом.

В этом уроке мы будем изучать React Native – фреймворк от компании Facebook для создания нативных приложений под iOS и Android. У него много общего с другим очень популярным фреймворком от Facebook – React Javascript, который предназначен для построения декларативных пользовательских интерфейсов.

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

1. Часы CSS3 с jQuery

Эти часы созданы с использованием одного из основных инструментов CSS3 – rotate и с подключением библиотеки JQuery.

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

1. Freepik

www.freepik.com

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

Алгоритм воронки — это простой алгоритм поиска наипростейшего пути, проходящего через «порталы». Наиболее подробное описание можно найти по ссылке Efficient Triangulation-Based Pathfinding (2)
Здесь же этот алгоритм будет реализован до одури просто. Вместо использования очередей и прочих очешуительных вещей, наша простейшая реализация перезапускает цикл каждый раз, когда обнаруживает очередной угол. Это значит, что некоторые порталы будут опрашиваться таки чаще, чем должны были бы, тем не менее, делая реализацию всяко проще.

Существует несколько видов DOM-узлов, в частности Document, Element, Text и многие другие, которые формируют общий узел Node. Одним из наиболее интересных узлов является DocumentFragment, несмотря на то, что до настоящего момента он практически не использовался. Он, по большей части, является специальным контейнером для других узлов.

DocumentFragment обрабатывается в большинстве алгоритмов DOM особым образом. В этой статье мы рассмотрим некоторые методы API, разработанные для использования вместе с DocumentFragment. Также мы узнаем, что понятие контейнера узлов играет важную роль в прочих современных веб-технологиях, таких как элемент template или в API всего теневого DOM. Но прежде чем мы начнем, давайте вкратце рассмотрим парсинг фрагментов, который не связан напрямую с DocumentFragment.

Эта статья — вторая часть перевода выступления Джона Нески (John Nesky) с GDC14.

Первая часть тут.

#26 Оставлять угол съёмки постоянным в то время, как персонаж бежит по склону

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

* — в трёх измерениях.


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

«Что может быть проще самолёта? Подъёмная сила пропорциональна квадрату скорости, двигатель тянет вперёд, всё просто» — такая мысль пришла в мою голову летом, и я сел писать игру. Лето прошло, было собрано несколько граблей, а списочек того, что я планировал добавить в проект, очень сильно вырос.

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

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

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

Человеку давно свойственно интересоваться окружающим миром и находить объяснения тому окружающим вещам и событиям. Собственно, без этого человек не стал бы человеком. На базе верований, мифов развивалась сначала религия, а потом — и современная наука, которая уже весьма успешно объясняет окружающий мир от очень малых до впечатляющих масштабов. Но всегда оставались люди, которые противились прогрессу и распространяли устоявшиеся мифы, уверяя, что они отвечают на все вопросы и незачем двигаться дальше. Гром гремит — это Перун-громовержец злится; кто-то заболел — это Бог его наказывает, вот тебе объяснения, отстань, не задавай вопросов, а лучше помолись.
Современные мифы более глубоки и обычно связаны с наукой. Причины понятна — наука развилась (особенно в последнее время) до такой степени, что часто нужен колоссальный объем знаний, чтобы просто понять, о чем вообще идет речь. У многих людей этого объема нет или безвозвратно потерян, что и снижает их сопротивляемость к разного рода мифам нашего времени. Миф про вредность пищевых добавок Exxx; миф про полезность натурального и вредность «химии»; миф про врачей-убийц, травящих людей прививками; миф про настолько страшное ГМО, что наклейки с надписью «без ГМО» надо клеить даже на салфетки и на пачки с солью.

Что такое ГМО? Зачем они нужны? Как велика опасность и польза от их использования? Есть ли доказательства безопасности этих организмов?

Под катом перевод огромной статьи, написанной Майклом Чёрчем и посвящённой стартапам. Статья вызвала необыкновенное бурление… мнений, скажем так, на разных сайтах и агрегаторах, поэтому я решил её перевести на русский и посмотреть на реакцию. Текст ОЧЕНЬ длинный, но также и очень интересный. И несколько пояснений перед чтением: в статье речь идёт об инженере в стартапе, именно с этой позиции всё рассматривать; некоторые финансово-экономические термины, возможно, не очень адекватно удались и я буду рад любым конструктивным поправкам.

То, о чём я хочу рассказать, справедливо для июля 2012 г. 15 лет назад необязательно было так же, и не факт, что будет справедливо через год. Но в данный момент это абсолютно верно для большинства людей в достаточной степени, так что я считаю обязанным высказаться. Нынешний мир ИК-стартапов (ИК=инвестиционный капитал / venture capital) — я его нежно называю ИК-стан — является, мягко говоря, тотально напрасной тратой времени для большинства вовлечённых людей.

Я никогда не упирался в лимит свободного почтового места в gmail, пока не стал форвардить рабочую почту в персональный аккаунт. Могу допустить, что вы и без рабочих вложений достигли 10гб лимита и отчаянно вылавливаете старые письма с большими и ненужными вложениями от всяких рекламных рассылок и анонсов. 
Более хитрые пользователи использовали специально заточенные под это сервисы, кто-то перелопачивал письма вручную, но теперь для этого (и не только) появились новые поисковые операторы…

В начале лета я выложил своё приложение в Google Play и Samsung Apps.



У Samsung странное понимание совместимости устройств и они требуют отдельный файл для каждой группы смартфонов/планшетов исходя из разрешения экрана.

В результате ссылка на версию для Samsung Galaxy S3, например, одна, а вот для Galaxy Note
совсем другая. Хотя сами файлы идентичны.

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

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

Под катом графики сравнения распределения пользователя по странам, версиям Android и пр.

В этой статье я подробно расскажу и покажу, как правильно и быстро прикрутить распознавание русской речи на движке Pocketsphinx (для iOS порт OpenEars) на реальном Hello World примере управления домашней техникой.
Почему именно домашней техникой? Да потому что благодаря такому примеру можно оценить ту скорость и точность, которой можно добиться при использовании полностью локального распознавания речи без серверов типа Google ASR или Яндекс SpeechKit.
К статье я также прилагаю все исходники программы и саму сборку под Android.

При разработке игр часто возникает необходимость реализации следования некоторому маршруту. Например, персонажу нужно проложить путь из точки A в точку B. Допустим рассчитали его по какому-нибудь алгоритму поиска пути, идем. И тут оказывается, что из точки C в точку D идет другой юнит и пересекает нам дорогу и надо бы его обойти. Что делать? Постоянно перестраивать путь – накладно, много лишних вычислительных расходов, когда достаточно слегка изменить направление уже во время движения, чтобы избежать столкновения.
Виды изменения направления по ходу движения и есть steering behaviors.