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

Поделюсь теми, на которые подписан я:

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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

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

Прошлые статьи серии можно найти тут:

«Серьезное проектирование серьезного магазина. Часть 1. Исследования»
«Серьезное проектирование серьезного магазина. Часть 2. Модули интернет-магазина»
«Серьезное проектирование серьезного магазина. Часть 3. Карточка товара и не только»
«Серьезное проектирование серьезного магазина. Часть 4. Субституты, комплементы, сравнение и другие инструменты увеличения конверсии»

Регистрация / личный кабинет

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

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

Рис. 1. Личный кабинет.

Computer Science Center (образовательный проект ШАД Яндекса, компании JetBrains и Сomputer Science клуба при ПОМИ РАН), открывает запись на массовые открытые онлайн-курсы (MOOC) по основам программирования.

С 15 сентября 2014 года можно будет пройти следующие онлайн-курсы, подготовленные преподавателями CS центра:

1. Алгоритмы и структуры данных (А.С. Куликов)
2. Введение в архитектуру ЭВМ. Элементы операционных систем (К.В. Кринкин)
3. Программирование на языке C++ (А.В. Смаль)

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

Для создания и размещения онлайн-курсов СS Center использовал образовательный плеер Stepic. Проект Stepic существует с 2013 года и выделяется среди других образовательных платформ возможностями для автоматической проверки задач на программирование, например, безопасное исполнение пользовательского кода в песочнице (C++, Java, Python, Haskell, Octave), а также генерация и проверка рандомизированных датасетов. Cистема проверки задач Stepic была использована в ряде курсов на платформе Coursera, включая курсы от Калифорнийского университета в Сан-Диего и НИУ «Высшая школа экономики».

В июне к команде LinguaLeo присоединился Артур Думчев, рекордсмен «Книги рекордов России» по запоминанию, признанный эксперт в области развития памяти, тренер и консультант. Артур помнит число «Пи» до 22 528 знаков после запятой и является автором книги «Помнить все. Практическое руководство по развитию памяти».

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

Разумное применение мнемотехники

Мнемотехника — это совокупность приемов, облегчающих запоминание. Пример использования мнемотехники: нам нужно занести в память слово Shrug — «пожимать плечами». Чтобы это сделать, достаточно представить какой-нибудь визуальный образ, который позволит вам вспомнить слово и его перевод. Например, Шрек пожимает плечами. Когда вы услышите Shrug, вам тут же вспомнится этот образ, а затем перевод слова.

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

Не знаю, как у вас, но у меня любимая часть интервью — логические задачи.
Довелось пройти немало собеседований на вакансию разработчика, поэтому набралась небольшая коллекция.
Спешу поделиться с вами!

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

Недавно написал свой велосипед и выложил его на хабре. Вот он: «Простейший Connection pool без DataSource в Java». Статья не из самых удачных, только прошу больше не минусовать. Итак, чтобы не повторять такие ошибки самому и, возможно, предостеречь кого-то от таких ошибок, решил перевести статью «Seven Things You Should Never Code Yourself» достаточно известного в среде open-source деятеля IT-области — Andy Lester'а. Итак, кому интересно, прошу под кат.

Эта статья иллюстрирует т. н. компромисс скорости и памяти — правило, которое выполняется во многих областях CS, — на примере разных реализаций хеш-таблиц на Java. Чем больше памяти занимает хеш-таблица, тем быстрее выполняются операции над ней (например, взятие значения по ключу).

Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

Сегодня публикуем статью нашего коллеги Дмитрия Коткина, уже полюбившегося хабровчанам по теме противостояния давлению в переговорах.

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

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”

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



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

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

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

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



Думаю, каждый из вас при очередном релизе задавался вопросами: «Точно ли мы отсылаем верный запрос?» или «Точно ли мы передали все необходимые параметры этому сервису?». Всем должно быть известно и о существовании негативных сценариев развития событий наравне с позитивными. Это знание должно активно порождать вопросы из серии «Что если..?». Что если сервис станет обрабатывать соединения с задержкой в 2 часа? Что если сервис ответит абракадабру вместо данных в формате json?

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

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

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

Ценник должен быть с печатью или подписью. Он является документом и обязательно должен быть на товаре. Если вы видите что-то с ценником (неважно, где и как оно стоит), вы имеете право купить его по цене на нём.

Пример: вам говорят, что товар по акции кончился. Вы видите один в витрине в герметичном ящике под потолком, но с ценником. Вам не имеют права отказать в его продаже.

Второй пример: когда обновляются цены, в торговом зале может остаться ценник со старой ценой ниже. Цена в базе другая? Ну и что, вот ваш же документ. Если же вдруг ценник без печати-подписи, и на таком товаре нет правильного ценника — регистрируйте нарушение. Ценники обязательно должны быть хотя бы на одном товаре из пачки.

От переводчика. Давид Хейнемейер Ханссон данной статьей поднял острую тему обязательности использования TDD и, даже, возможного вреда от написания тестов перед написанием кода. Именно эта статья послужила лейтмотивом уже пяти встреч на тему жив ли TDD, на которых Давид, Кент Бек и Мартин Фаулер обсуждают достоинства и недостатки TDD, рамки применимости и ограничения. Для тех у кого восприятие устного английского оставляет желать лучшего, SergeyT публикует краткие саммари в своем G+.

Почти два года назад вышла статья «What no one told you about z-index» (и её перевод на Хабре «То, что вам никто не говорил о z-index»), авторы которой рассказывают о малоизвестной (76% проголосовавших пользователей Хабра слышат об этом впервые), но документированной возможности создания нового контекста наложения указав opacity меньше единицы.

Но несмотря на название статьи, авторы не рассказали вам ещё кое о чём.


Новый контекст наложения формируется в случаях:

• Корневой элемент () всегда содержит корневой контекст наложения. Любой элемент на странице, не участвующий в локальном контексте наложения (сформированном любым из последующих вариантов), участвует в корневом контексте наложения.
  Элемент с position отличным от static и значением z-index отличным от auto. Кроме одного исключения для position: fixed, но я это вынес в отдельный пункт.
  Элемент имеет значение opacity меньше, чем 1.
  

В релизе Java 8 появился новый класс Optional призванный помочь разработчикам в обработке NullPointerException.

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

А что если вообще запретить назначать тем или иным полям класса значения равные null? Java естественно не запрещает нам делать этого, но с Optional это становится немного удобнее и нагляднее.

Итак, приступим к описанию основных возможностей этого нововведения.

Как известно, в Java нет беззнаковых типов. Если в Си вы могли написать unsigned int (char, long), то в Java так не получится. Однако нередко возникает необходимость в выполнении арифметических операций именно с числами без знака. На первый взгляд кажется, что беззнаковые типы в принципе-то и не особо нужны (подумаешь, MaxInt для чисел со знаком меньше в два раза, если нужны числа больше, я просто возьму long и далее BigInteger). Но основное различие на самом деле не в том, сколько различных неотрицательных чисел можно положить в signed или unsigned int, а в том, как над ними производятся арифметические операции и сравнения. Если вы работаете с бинарными протоколами или с двоичной арифметикой, где важен каждый используемый бит, нужно уметь выполнять все основные операции в беззнаковом режиме. Рассмотрим эти операции по порядку:

Преобразование byte в short (int, long)

Обычный каст (int) myByte выполнит расширение до 32 бит со знаком — это означает, что если старший бит байта был установлен в 1, то результатом будет то же самое отрицательное число, но записанное в 32-битном формате:

0xff -> 0xffffffff (-1)

Часто это не то, чего бы мы хотели. Для того, чтобы выполнить расширение до 32 бит без знака и получить 0x000000ff, в Java можно записать:

int myInt = myByte & 0xff;
short myShort = myByte & 0xff;

Сравнение без учёта знака

Для беззнакового сравнения есть лаконичная формула:

int compareUnsigned(int a, int b) {
    return Integer.compare( a ^ 0x80000000, b ^ 0x80000000 );
}

Для byte, short и long, соответственно, константы будут 0x80, 0x8000 и 0x8000000000000000L.

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

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