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

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

Итак, все кругом твердят вам, что при получении времени от пользователя нужно сразу же переводить его в UTC, работать со временем нужно только в UTC и хранить время тоже нужно строго в UTC. Совет, на первый взгляд, выглядит разумным, и следование ему делает вашу жизнь проще… Если только ваша программа не предполагает сложной работы с датами. Записать в базу данных дату и время регистрации пользователя на сайте? Сохранить время отправки сообщения или дату создания заказа в интернет-магазине? Вывести сообщение в лог с указанием даты-времени? Используйте UTC и всё будет в порядке, можете даже не читать эту статью дальше. Любое текущее время можно совершенно спокойно конвертировать в UTC и забыть о проблемах. Но что, если мы хотим работать с временем в будущем? Или в прошлом? Например, если мы пишем сервис календаря, или сервис для отложенной отправки сообщений?

Недавно я получил письмо от читателя моего блога, которое, по какой-то причине, заставило меня задуматься. Письмо гласило:

Привет Филип, можно спросить, как ты стал отличным front-end-разработчиком? Можешь дать совет?

Признаться, я был удивлен тем, что подобный вопрос задают мне, так как я никогда не считал себя «отличным» front-end-разработчиком. На самом деле, я не уверен, что был достаточно квалифицирован для всего, за что брался, когда только начинал работать в этой сфере. Я подавал заявки на работу только потому, что не понимал, как мало я знаю, а получал её, потому что люди, на собеседование к которым я приходил, не знали, какие вопросы задавать.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

В пятой редакции ECMAScript был представлен строгий режим (далее в статье Strict Mode). Strict Mode накладывает слой ограничений на JavaScript, он отгораживает вас от опасных частей языка (те части, которые есть исторически, но лучше чтобы их не было) и позволяет снизить вероятность ошибки.

Пока читал эту статью я написал 38 тестов, покрывающих все правила Strict Mode, объявленные в спецификации ES5. Вы можете посмотреть насколько ваш браузер поддерживает эти справила вот тут.



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

Firefox 4 уже полностью поддерживает Strict Mode, а Chrome 11 практически полностью. Strict Mode уже не за горами — давайте изучим его подробнее!

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

До того, как я пришел в HeadHunter, я не знал, что такое code review. Я знал, что такое code approval — так было в одной американской компании, где я начинал свою карьеру, и где весь код в проекте проходил перед мудрыми глазами профессора Фортрана за столиком в глубине офиса. Он с отеческой улыбкой смотрел на мои первые шаги в разработке и говорил: «Вот тут поправь, пожалуйста, и можешь выпускать».

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

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

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

Интернет сделал нас ленивыми!

Почему? Кто в последний раз посмотрел видео больше 3х минут? Кто прочитал пост больше 2 страниц? Какой заголовок более привлекателен, «63 способа бла-бла-бла» или «3 проверенных метода бла-бла-бла»? А если эти три проверенных метода выделены от основного текста, то это вообще гуд (можно не читать текст вовсе, а просто пробежаться по выделенным подзаголовкам).

В этом свои плюсы. Наш мозг эволюционировал, и обрабатывает информацию быстрее, чем, скажем, 15-20 лет назад (да и эволюционирует быстрее, чем это было возможно век назад). Как компании справляются с высокими нагрузками? Как процессор выполняет программу по возможности быстро? С помощью кэширования! (как вариант, но самый приоритетный). Что делает наш мозг, чтобы справиться с большой нагрузкой? Кэширует! Что именно и как — оставим на размышление ИИшникам (специалистам по искусственному интеллекту). В противном случае при увеличении размера обрабатываемой информации время «отклика» бы увеличилось в разы, и на ответ на «как добраться до ближайшей больницы?» уйдет больше времени, чем человек «в силе ждать». «Сила ждать» тоже уменьшилась, «размер» нашего терпения уменьшился, и мы быстро устаем, если продолжительность видео большая, размер статьи большой (на самом деле продолжительность может не влиять на терпение, больше всего влияет полезная информация, если «воды» меньше или вовсе нет, то и терпеть ничего не приходится, посему данный пост написан «эз лаконик эз посибл»).

Я разместила иконки курсов Стэнфордского университета по разработке приложений на iOS в обратном хронологическом порядке. На первом месте стоит иконка Swift — нового языка программирования для создания приложений на iOS, объявленного на WWDC 2014. Кроме Swift реализована новая версия iOS — iOS 8. Уже известно, что Стэнфордский университет запустит зимой 2015 года новый курс CS193P с неизвестным пока названием (может быть будет что-то вроде «Developing iOS 8 Apps for iPhone and iPad»). Лектор тот же — профессор Paul Hegarty.
В традиции Стэнфорда выкладывать курс CS193P на iTunes U в виде бесплатного курса обучения, но делают это они со сдвигом во времени, чтобы не мешать платному обучающему процессу, так что в феврале-марте 2015 года (как это было в 2013 году) можно ожидать постепенное появление лекций на iTunes U. Так что время есть.
Я прошла почти все курсы профессора Пола Хэгарти — от iOS 5 до iOS 7 — до самого конца (смотри Github ).
Для подготовки к перспективному курсу по iOS 8 разместила на своем сайте «Разработка iOS приложений» неавторизованные конспекты лекций, тексты домашних заданий и примеры их решения на русском языке для последнего доступного в настоящее время обучающего курса «Developing iOS 7 Apps for iPhone and iPad», запущенного Стэнфордским университетом в семестре «осень 2013 — зима 2014 года» на iTunes U.

Перед разработчикам, которые используют API Яндекс.Карт, довольно часто встаёт задача отобразить много объектов на карте. Действительно много — порядка 10 000. Причем эта задача актуальна и для нас самих — попробуйте поискать аптеки на Яндексе. На первый взгляд кажется: «А в чем собственно проблема? Бери да показывай». Но пока не начнешь этим заниматься, не поймешь, что проблем на самом деле целый вагон.



Вопросы по большому количеству меток с завидной регулярностью поступают в наш клуб и техподдержку. Кто все эти люди? Кому может быть интересно показать на карте больше 10 меток? В этом посте я подробно рассмотрю весь вагон проблем и расскажу, как в API появились инструменты, помогающие разработчикам оптимально показать большое количество объектов на карте.

Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
— С просторов интернета

К чему это я? Занятная штука — JavaScript. Основа современного web и на фронтэнде альтернатив как таковых не имеет.

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

Ванильная стандартная библиотека JavaScript, в целом, неплоха. Это не только стандартная библиотека по спецификации языка ECMA-262 актуальных версий — от 3 до черновика 6. Часть API вынесена в отдельные спецификации, например, API интернационализации ECMA-402. Многие возможности, без которых сложно представить JavaScript, например, setTimeout, относятся к web-стандартам. Консоль не стандартизована вовсе — приходится полагаться на стандарт де-факто.

Вот только не такая уж она и стандартная — везде разная. Есть старые IE, в которых из коробки мы получаем стандартную библиотеку ES3 90-бородатого года даже без Array#forEach, Function#bind, Object.create и консоли, и есть, например, Node.js, на которой многие уже вовсю используют возможности грядущего ES6.

Хочется иметь универсальную, действительно стандартную библиотеку, как на сервере, так и в любом браузере, максимально соответствующую современным стандартам, а также реализующую необходимый функционал, что (пока?) не стандартизован. Статья посвящена библиотеке core.js — реализация моих соображений по поводу стандартной библиотеки JavaScript. Кроме того, эта статья еще и шпаргалка по современной стандартизованной стандартной библиотеке JavaScript и заметки о её перспективах.

Содержание, или что получим на выходе:

• Подходы

• Часть первая: Костыли

  
  
  • ECMAScript 5
  • ECMAScript 6
  • ECMAScript 6: Символы
  • ECMAScript 6: Коллекции
  • ECMAScript 6: Итераторы
  • ECMAScript 6: Обещания
  • Mozilla JavaScript: Статические версии методов массива
  • Отложенное исполнение: setTimeout, setInterval, setImmediate
  • Консоль
  
  

• Часть вторая: Велосипеды

  
  
  • Классификация данных
  • Словари
  • Частичное применение
  • Форматирование даты
  • Объектное API
  • Массивы
  • Числа
  • Экранирование спецсимволов
  
  

• Заключение

Тут народ спрашивал об особенностях акриловой краски, и где ее купить. Я подумал, что не помешало бы тогда еще и рассказать подробнее о технологии ее нанесения на ткань, и решил вынести рассказ в отдельный топик.

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

Сначала смотрим видео…


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

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

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

В топике о десятимерном пространстве, помимо идей об употреблении веществ и всяких астральных проекциях, высказывались идеи о четырёхмерной игре, чтобы «посмотреть, как это выглядит».
Тут имеется ввиду 4 пространственных измерения.
Фокусы с ветвлением и наложением во времени есть в играх типа Chronotron и аналогичных.

Работая над крупным, постоянно развивающимся проектом, почти ежедневно имею дело с различными формами утверждения задач: от «Очень срочно, поправь тут. За час уложишься?» до «Оцени, на сколько недель потянет эта задачка». Я, как исполнитель, сам оцениваю время и сложность выполнения каждой задачи и считаю это единственным правильным подходом к оценке фронта предстоящих работ в сфере разработки ПО.

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

Принципы

Обобщив накопленную по теме оценки сроков информацию, получил следующие принципы оценки сроков выполнения работы:

Рекомендации по html-коду, вёрстке и немного — по копирайтингу. Актуально для февраля-2009

Это не очередной список «101 совет, как достичь идеала в том-то», которых полно в интернете. Это «инсайдерская информация» SEO-компании, ведущей более 600 проектов. Перечислено то, на что мы обращаем внимание, начиная поисковую оптимизацию. Разумеется, не всё получается реализовать (например, движок сайта что-то не позволяет, а где-то пункты противоречат(!) друг другу). Ничего страшного. Если больше половины рекомендаций получается реализовать, то это уже очень хорошо!

Если кто не знает, то в гугле можно задавать искомый размер картинки в пикселях, например:
imagesize:256x256 filetype:png firefox

Компьютер давно уже стал таким же обычным предметом в доме, как и например холодильник. Но почему-то многие пользователи компьютеров, особенно не сильно «продвинутые» считают, что современный компьютер должен шуметь. Он ведь мощный, ему нужен БП на XXX ватт, а шум — это неизбежность. Однако для большинства типичных домашних конфигураций это не так. Их можно сделать как минимум тихими, а то и вовсе практически бесшумными. Далее я расскажу, как добиться этого без значительных финансовых вложений простыми и доступными средствами.