Не так давно AWS Amazon представил сервис, именуемый AWS Test Drive. Мне повезло, в рамках совместной программы AWS Amazon и нашей компании я смог познакомиться с этим сервисом поближе и опробовать его функционал. Для начала хочу вкратце рассказать, что же это такое и зачем оно надо.

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

В данной статье будет разобрано, как работать с координатами и часовыми поясами:
А именно,

1. Установка Google Maps, рассмотрен небольшой функционал с примером.
2. Поиск часового пояса с по координатам (Geonames.org).
3. Поиск координат и часового пояса по названию города (Geonames.org).
4. Определение названия местности по координатам.

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Видимо, вспышки на солнце [в том числе] послужили причиной написания постов про сознание и про 200 мс свободы.

А так как я с другой стороны планеты, то вот и меня догнало.

Свойство психики и потребность

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

На тему систем централизованного управления конфигурациями на Хабре написано немало статей и, в частности, про Chef есть несколько хороших статей. Однако, количество релизов Chef растет, и я решил немного освежить его описание для читателей Хабра. Статья предназначена как для новичков, так и для тех, кто уже знакомился с системой, но по какой-то причине отложил изучение и хочет все-таки продолжить. А продолжать стоит! Поскольку, Chef полезен и для администрирования нескольких VPS, и для управления большим парком серверов. Особенно, если вам часто приходится заниматься настройкой серверов с нуля, подключением дополнительных нод в кластер и т.д.

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

Уровень слова

Ни для кого не секрет, что существует коммерческая градация авторов, которая напрямую отражается в «номинальной» ценности их работ и уровне подачи информации.

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

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

Исключения и связанная с ними раскрутка стека – одна из самых приятных методик в C++. Обработка исключений интуитивно понятно согласуется с блочной структурой программы. Внешне, обработка исключений представляется очень логичной и естественной.

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

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

Если спросить у десяти разработчиков о лучшей (или достойной) книге о проектировании, то как минимум 6 из них назовет книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки». Если же после этого показать им на некоторые интересные моменты писанины «дядюшки» Боба, то большая часть из них с недоумением почухает лоб и несколько изменит свое мнение.

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

Предыдущий перевод (Landing page, которая работает), посвященный дизайну качественных посадочных страниц набрал больше 150 000 просмотров. С тех пор прошло уже много времени и подход к дизайну изменился – все больше становится минималистичных страниц, о которых и пойдет речь в статье.

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

Всем привет!

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

Меня зовут Сергей. Чтобы сказать про себя «я плохой докладчик», нужно хотя бы им, докладчиком, быть. Я вообще не оно. Свою первую и одну из последних презентаций я провел в 18 лет в Испании, перед аудиторией человек в 100. Мой весьма средний на тот момент английский синхронно переводили на испанский, народ зевал и почесывал репы, ожидая когда ЭТО недоразумение закончит блеять и объявится кофебрейк.

Сказать что мне было стыдно — это ничего не сказать, красный как рак, я свалил вторым выходом, забился в свой номер и боялся показаться на глаза. Всякие public professionals типа Карнеги сказали бы «позор!» и «never again!». Для себя я решил — все что угодно, хоть жигулевское пиво по пятницам, только не публичные экзекуции

К чему это я? Многие, глядя на ИТшников, путают скромность со стеснительностью. Да и фиг с ними. Главное — чтобы мы сами не путали. Я — стеснительный, поэтому буду смотреть в пол и читать по бумажке. Я бы выпил, конечно, для смелости, граммчиков сто (а лучше сто пятьдесят), но организаторы запретили. Ну что, пусть фигово, зато честно!

Я владелец компании П, в которой мы уже лет 13 или 14 занимаемся разработкой всякой фигни, про которую никто не слышал. Не имея таланта делать что-то красивое и эстетичное, мы довольствуемся подводной частью айсберга: софт-свитчи и клиенты для IP-телефонии, аппаратно-программные решения для высоконагруженных систем обработки контента, системы имперсонализации web и e-mail для виртуального присутствия, облачное видеонаблюдение, несколько справочных и торговых интернет-порталов, ну и еще пара проектов в стадии стартапа, говорить о которых рано, потому что стыдно

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

Как-то стал свидетелем разговора двух приятелей и услышал:
«У вас уже внедряют DevOps? Просто у нас в МегаТелеКо все идет полным ходом! Недавно мы набрали команду DevOps из 35 человек!»

Так почему нанять команду DevOps это плохая идея?

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

• автоматизацией изменений в инфраструктуре
• настройкой JIRA
• администрированием MySQL
• поддержкой масштабных Linux проектов
• ведением всего, что связано с puppet
• написанием скриптов на ruby, python или bash
• оперативным подпиранием «костылями» тут и там

Команда многострадального торрент-трекера PirateBay рассказала о своих планах на будущее, в частности о том, как именно планируют бороться с блокировками сайтов, занимающихся раздачей нелегального контента.

Технически речь идёт о создании новой P2P-платформы, клиентами которой будут как отдельные приложения, так и плагины для Firefox или(и) Chrome. В частности, сайт, который захотел бы присоединиться к идее PirateBay, при посещении предлагает установить пользователям некоторое расширение или плагин, который по сути сохраняет содержимое базы данных трекера локально для всех, кто позволит это сделать. Таким образом получается, что для жизни такого «супер-распределенного» трекера достаточно обеспечить только минимальный интерфейс для возможности поиска и сидирования контента, а в случае его центральной блокировки все ссылки будут доступны через P2P-сеть от других пользователей.

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

Вот основные стадии книги — от замысла, до выхода в свет:

Вероятно, большей части хабрасообщества в 1964 году даже в проекте не было. Однако, в то время жил и работал великий (не побоюсь этого слова) писатель-фантаст, мыслитель, ученый, популяризатор науки и просто человек Айзек Азимов. В 1964 году, находясь под впечатлением от Всемирной выставки, проходившей в Нью-Йорке, он решил представить, как будет выглядеть мир через полвека. В этом, 2014 году, как раз исполняется 50 лет этому предсказанию, поэтому предлагаю вспомнить те предсказания Азимова, что сбылись.

SAT уже тем хорош, что он ум в порядок приводит
Ломоносов (оригинал)

Введение

На хабре уже немало статей, посвященных проблеме P vs. NP и задаче о выполнимости логических формул (SATisfiability problem). Однако, большинство из них не отвечает на несколько самых важных вопросов. Почему эта проблема действительна важна для нас? Что будет, если её решат? Где это все вообще применяется? И почему необходимо иметь хотя бы общее представление, о чем там идет речь?



Если мы детально проанализируем наиболее заметные работы на хабре по данной теме [1, 2, 3, 4, 5, 6, 7], то заметим, что с одной стороны, люди обладающие знаниями в области вычислительной сложности не cмогут почерпнуть ничего принципиально нового в данных статьях. С другой стороны, данные статьи по-прежнему не являются общедоступными. Иллюстрация из заголовка наглядно демонстрирует проблему: тем, кому было не понятно, из неё ничего не ясно, а те, кто об этом уже слышал, в ней не нуждаются.

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

Test Driven Development (TDD) – неоспоримо выдающаяся техника, дающая ряд преимуществ. Прикладные разработчики, причём вне зависимости от масштаба проекта и количества вовлеченных специалистов, в широкой массе не следуют TDD. Но есть и ярые сторонники такого подхода, причём они готовы апеллировать не только к здравому смыслу или производственной необходимости, но и на безоговорочно успешные примеры его внедрения. Одним из таких апологетов является Александр Люлин, который не только рассказывает о степени позитивного влияния TDD на разработку, но и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники вплоть до исходных кодов и примеров сценариев (в своем блоге). Однако главный тормоз на пути следования принципам TDD стоит, что предсказуемо, набор чисто психологических установок. В режиме «жёсткого разговора» мы пообщаемся с Александром на тему необходимости Test Driven Development.

Test Driven Development – попытка следования моде? Слепое копирование чужих подходов?

Давайте «сразу определимся». Я не использую TDD в его классическом понимании. И не надо здесь цитировать «википедию»! Вообще, вряд ли кто-то из профессионалов рассматривает энциклопедические статьи в качестве руководства к действию. Мы свой подход «выстрадали» в рамках реализации успешного проекта, поэтому за нами реальный опыт, а не «тупое использование чужих идей». Скорее, мы используем синтез из TDD и собственных представлений о том, как нужно разрабатывать ПО. Даже если эти «внешние идеи» исходят от очень умных людей, их следует критически осмыслить и адаптировать к реальной компании, существующей команды и стратегии развития и обеспечения качества. Но я далее буду говорить «TDD», имея ввиду тот процесс “разработки через тестирования», который близко соотносится с энциклопедическим Test Driven Development, но идёт гораздо дальше него.

TDD — это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

Вспомнить данный прогноз натолкнул меня пост «15 вещей сегодняшнего дня, которые не застанут наши дети».
Автор прогноза основатель компании «Демос» Давидов Михаил Изгияевич. Прогноз был дан в статье, посвященной десятилетию «Демос» и опубликован в декабре 1998 года.

Мне бы хотелось привести этот прогноз здесь, дабы посмотреть насколько точен он оказался.

PS. Я знаю, что на хабре не приветствуется кросспостинг, но я не мог не привести данный текст полностью. Я лишь позволил себе исключить несущественные на мой взгляд детали.
В любом случае оригинал можно прочитать по адресу news.demos.su/private/demos.html

Несколько лет назад мы – авторы данного материала – изрядно покопавшись в патентах, дневниках и лекциях Н.Теслы (благо, образование позволяло) пришли к выводу, что пресловутая Башня Тесла по передаче энергии не «фейк», а вполне рабочая конструкция.

В результате нескольких лет исследований, размышлений, изучения первоисточников, сопоставления данных, формирования и отсеивания гипотез и т.п. – появилась красивая и, по сути, простая модель, которая строго вписалась в классическую физику и была подтверждена численным моделированием в пакете Ansoft HFSS. С момента начала проекта, мы провели некоторое количество дискуссий в различных сообществах, где от нас требовали «статью для технарей» — в результате появился данный материал.

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

Во-первых, JSON Template это не JSON.
Во-вторых, если у Вас нет представления о том чем является JSON или как он выглядит, посмотреть лучше здесь.

Секции и Повторяющиеся секции

Секции выполняют большую часть работы в JSON Template. Есть всего две важные идеи, которые мы должны знать о секциях:

1. Содержимое секции отображается только если секция существует.
2. Секция определяет область видимости, являясь корневым разделом для любых, добавленных в нее, данных.