Кажется, мне довелось сделать десятки презентаций для коллег, заказчиков и публичных выступлений за мою карьеру в IT. Многие годы Powerpoint как средство изготовления слайдов оставался для меня естественным и надёжным выбором. Но в этом году ситуация качественно изменилась. С февраля по май мне довелось выступить на пяти конференциях, и слайды к докладам надо было готовить в сжатые сроки, но качественно. Встал вопрос о делегировании той части работы, что касается визуального дизайна слайдов, другим людям. Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах. И я решил попробовать что-то новое. Попробовал, и с тех пор не думаю возвращаться к Powerpoint.

Привет, Хабр. Мы недавно перевели на арабский язык 2ГИС Онлайн, и хотим поделиться своим опытом адаптации интерфейса под RTL (right-to-left). Это будет актуально и для иврита, и для персидского языка.

Я разделю этот опыт на две статьи — теоретическую и практическую. Сегодня — больше про теорию. Я расскажу, зачем нам понадобилось переворачивать весь интерфейс, что для разработчика интерфейсов значит фраза «сделать арабскую версию» и как справиться с арабским языком, смешанным с английским. Особое внимание уделю алгоритму, по которому строится отображение текста смешанной направленности — unicode bidirectional algorithm.

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



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

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

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

На днях я читал материалы на MDN и наткнулся на некоторые довольно интересные возможности и API JavaScript, о существовании которых я не знал. Хочу сегодня о них рассказать.

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

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



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

Уважаемые коллеги, добрый день.

В связи с тем, что 14.12.2017 года W3C в блоге объявила о выходе новой редакции HTML 5, предлагаю Вашему вниманию краткое описания основных нововведений.

Новации

1. Поддержка модульного JavaScript

   
   На мой взгляд, самая интересная и ожидаемая новация связана с поддержкой модульного синтаксиса последнего стандарта ECMA Script.
   

Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.

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

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

Что не так с тестированием вёрстки

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

Проблема тестирования вёрстки в том, что только живой человек может сказать, хорошо свёрстан блок на странице или нет. Поэтому чаще всего мы тестируем HTML и CSS вручную: проверяем, как будет вести себя блок, если в нем будет слишком много (или слишком мало) текста или дочерних элементов; смотрим, чтобы все возможные варианты отображения блока смотрелись корректно; помним о том, как блоки должны адаптироваться к разным устройствам и разрешениям экрана.

Добрый день.

Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.

Знаки препинания — неотъемлемая часть любого языка. Обычная запятая может кардинально изменить значение предложения: достаточно вспомнить историю с «Казнить нельзя помиловать». А работа переводчиков и редакторов предполагает, что они свободно ориентируются как минимум в двух пунктуационных системах.

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

Здравствуйте, уважаемые хабровчане! Мы решили возобновить публикации еще до окончания больших праздников, но в сегодняшней статье все-таки раскрыта тема справедливой раздачи подарков. Сама же статья, как понятно из названия, посвящена сравнительному анализу параллелизма и конкурентности.

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

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



Читабельность — одно из важных свойств любого тест-кода. Один мой сотрудник даже утверждал, что читабельность тестов важнее читабельности основного кода, т.к. именно тест будет входной точкой при попытке разобраться, как работает какой-либо функционал в приложении. Мне эта идея понравилась, и я решил применить ее для визуальных тестов в Galen Framework. Моей целью было написать тест, прочтя который, станет понятно, как должен выглядеть сайт в разных размерах браузера. Давайте взглянем на самые распространенные случаи при тестировании верстки адаптивного сайта и попробуем разобраться, как же улучшить наши тесты.

Как-то увидев очередную статью на Хабре, посвященную для меня совершенно новому и неизведанному языку Go, решил попробовать, что это за зверь и с чем его едят (В основном, конечно, понравился логотип). Конечно, язык имеет много возможностей и достаточно удобен. Но что меня сразу удивило, это отличный от C-подобных языков принцип объявления переменных, а именно тип переменных описывается справа от имени переменной. У меня как человека, практически выросшего на С, это вызывало удивление. Потом я конечно вспомнил Pascal, что там тоже тип переменной был справа. Заинтересовавшись этим вопросом, я попытался разобраться, почему используется тот или иной синтаксис описания типа переменных в этих 2-х языках.

Как должно быть очевидно, одна из целей этого сайта — убедить принимать F# всерьёз в роли универсального языка разработки.

Но в то время как функциональный стиль всё больше проникает в массы, и C# уже получил такие функциональные средства как лямбды и LINQ, кажется, что C# всё больше и больше наступает на пятки F#. Так что, как это ни странно, но я стал всё чаще слышать как высказывают такие мысли:

• «C# уже обладает большей частью инструментария F#, и зачем мне напрягаться с переходом?»
• «Нет никакой необходимости что-то менять. Всё, что нам нужно сделать, так это пару лет подождать, и C# получит достаточно от F#, что обеспечит практически все плюшки.»
• «F# только чуть лучше, чем C#, но не настолько, чтобы в самом деле тратить время с переходом на него.»
• «F# кажется действительно неплох, хоть и пугает местами. Но я не могу найти ему практического применения, чтобы использовать вместо C#.»

Не сомневаюсь, что теперь, когда и в Java тоже добавлены лямбды, подобные комментарии зазвучали в экосистеме JVM при обсуждении «Scala и Closure против Java».

Так что в этой статье я собираюсь отойти от F# и сосредоточиться на C# (а на его примере и на других популярных языках), чтобы показать, что даже с реализацией всех мыслимых средств функциональных языков программирование на C# никогда не будет таким же, как на F#.

Представляю вашему вниманию перевод очень ёмкой, и в то же время достаточно краткой (для такого масштаба проблемы) статьи Карла Чео. Я решил, что очень хочу сделать её перевод практически сразу, как только начал читать, и очень рад, что в итоге сделал это.

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

Важные замечания:

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

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

По блогу нашей компании может создаться впечатление, что мы занимаемся только data mining'ом и сетями. Поэтому я, как представитель девелоперского цеха, не смог отказать себе в удовольствии написать статью про то, как круто организовано unit-тестирование и разделение кода на модули у нас во фронтенде.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

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

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



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

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

Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.

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