Василий Иванов — молодой, талантливый и предприимчивый технический специалист — решил открыть свой бизнес, так как придумал мега-продукт. На старте бизнеса он уволился с работы, зарегистрировал ООО с 10 тыс. уставного капитала, вложил немного своих денег, взял небольшой кредит, нанял на работу 5-ых технических специалистов. Работа пошла, но через полгода оказалось, что у продукта нет будущего, деньги закончились, кредит не погашен, перед сотрудниками задолженность по зарплате за 2 месяца на сумму 400 тыс. рублей чистыми и перед бюджетом на сумму 204 тыс. рублей (примерно +51% от суммы задолженности перед сотрудниками, т.к. тут 13% НДФЛ, 31% ПФР + ФОМС и по мелочи). В общем, дела плохи, пора закрываться и возвращаться к работе «на дядю».

Вопрос: что делать Василию с долгами и ООО?

Мы в команде Web Development компании Itransition уже имеем хороший опыт разработки на Angular 2 и хотим им поделиться.

Эта статья ориентирована на тех крутых ребят, которые разрабатывают на Angular и подумывают перейти на вторую его версию.

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

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

Минувшая неделя совместила в себе такое количество космических событий, которого бы хватило на месяц минимум. Запуск и стыковка корабля «Шэньчжоу-11», аварии на юпитерианском зонде «Юнона», возвращение к полетам ракеты-носителя «Антарес», успех и неудача миссии «Экзомарс», запуск и стыковка «Союз МС-02». Неудивительно было что-нибудь пропустить, поэтому я сделал своеобразный космический дайджест, с новостями и комментариями к ним.

Эту книгу я перечитывал много раз, и в переводе, и в оригинале. Настолько много, что, рассказывая о ней, чувствую себя немного странно. Примерно как Капитан Очевидность, который вдруг осознал, что он Капитан.

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

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

Трудно научить криптографической безопасности даже умного человека. Особенно умного.

Названный одним из характерных представителей стиля «киберпанк», Нил Стивенсон в «Криптономиконе» возвращается к реальности дня сегодняшнего и даже уходит в прошлое (вплоть до древних греков), в попытке оценить роль «технарей» в современном обществе. Книга была опубликована в 1999 году, и 17 лет назад казалось, что автор испытывает чрезмерный оптимизм по поводу влияния компьютеров и интернета на человечество, рисует реалистичную, но в чем-то утопию. Сейчас так уже не кажется. Милые артефакты 20-го века вроде Windows NT и BeOS совершенно не мешают актуальности вселенной «Криптономикона». Технологии ушли вперед, но люди… Люди почти не изменились, как в хорошем смысле, так и в плохом.

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

Сергей Аверин ( XEK )

Изначально я хотел сделать доклад про сравнение фреймворков, но потом подумал, что закидают помидорами, поэтому доклад — просто адский троллинг, как водится у меня. И он, скорее, не про HighLoad, а про менеджерскую задачу, которая стоит над всем этим делом, включая фронтенд.

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

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

Автор: Антон Реймер

Статья основана на вебинаре, который я проводил некоторое время назад. Рассчитана она, в первую очередь на тех, кто не знает, как работают браузеры, или тех, у кого есть пробелы в знаниях. Вероятно, здесь будет много очевидного для тех кто не первый день в веб-разработке. Статью я решил разделить на две части. В первой рассмотрим общие принципы работы браузера. Во второй части я акцентирую внимание на некоторых важных моментах: reflow и repaint, event loop.

Что такое браузер?

Браузер — программа, работающая в операционной системе. Большинство браузеров написано на языке C++. Основное предназначение браузера — воспроизводить контент с веб-ресурсов. В качестве веб-ресурса в большинстве случаев выступает html-страница. Это также может быть pdf-файл, png, jpeg, xml-файлы и другие типы. Среди огромного количества браузеров можно выделить самые популярные: Chrome, Safari, Firefox, Opera и Internet Explorer. Мы рассмотрим браузеры с открытым исходным кодом: Chrome, Firefox, Safari.

Из чего состоит и как работает браузер?

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

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

Перевод статьи «5 Practical Examples For Learning The React Framework», Martin Angelov

Вы вероятно слышали о популярном JavaScript фреймворке от Facebook – React. Он используется на многих популярных веб-сайтах, в том числе в Facebook и Instagram. В этой статье вы увидите 5 практических примеров, построенных при помощи React, которые помогут вам начать работать с этим фреймворком.

Итак, я знаю что ты любишь Todo списки, то есть, что тебе очень нравится писать Todo списки, поэтому мне хочется, чтобы ты создал один из них, используя новый, восхитительный и питательный («nutritious» прим. пер.) Flux фреймворк, Redux! Я желаю тебе только лучшего.

В этой статье ты научишься как сконструировать свое собственное Redux приложение, не ограничиваясь, но так же включая.

• Цельнозерновой рендеринг на сервере
• Расширенный роутинг, богатый Omega-3
• Маслянистая асинхронная загрузка данных
• Гладкое функциональное послевкусие

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

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

Redux предлагает думать о приложении, как о начальном состоянии модифицируемом последовательностью действий (actions), что я считаю действительно хорошим подходом для сложных веб-приложений, открывающим много возможностей.

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

На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -11 и -12 смогли сесть, оказывается, только по счастливой случайности.

В первой части перевода речь пойдет о том, что такое UX, чем юзабилити отличается от визуального/графического дизайна, и что нужно сделать, начиная работать над интерфейсом продукта – будь то почтовая рассылка, веб-приложение или оффлайн-услуга. Это – хороший материал для тех, кто приступает к освоению данной области, и хочет разобраться, «как тут все устроено».

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

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

Напомню фрагмент кода:

while(total_free_mem <= 0)
    {
    wait_cond(&got_free_mem, &allocator_mutex);
    }

Здесь цикл вокруг wait_cond гарантирует нам, что даже если мы вернёмся из ожидания события случайно или по ошибке, ничего страшного не случится — проверка в while обеспечит нам уверенность, что нужное состояние проверяемого объекта достигнуто. Если нет — поспим ещё в ожидании.

Отметим ещё раз, что проверяем мы состояние объекта (total_free_mem <= 0) при запертом мьютексе, то есть никто не может его менять в то же самое время.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

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

В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

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

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

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

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

Итак, магия:


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

Когда я делаю ошибку в коде, то обычно это приводит к появлению сообщения “segmentation fault”, зачастую сокращённого до “segfault”. И тут же мои коллеги и руководство приходят ко мне: «Ха! У нас тут для тебя есть segfault для исправления!» — «Ну да, виноват», — обычно отвечаю я. Но многие ли из вас знают, что на самом деле означает ошибка “segmentation fault”?

Чтобы ответить на этот вопрос, нам нужно вернуться в далёкие 1960-е. Я хочу объяснить, как работает компьютер, а точнее — как в современных компьютерах осуществляется доступ к памяти. Это поможет понять, откуда же берётся это странное сообщение об ошибке.

Вся представленная ниже информация — основы компьютерной архитектуры. И без нужды я не буду сильно углубляться в эту область. Также я буду применять всем известную терминологию, так что мой пост будет понятен всем, кто не совсем на «вы» с вычислительной техникой. Если же вы захотите изучить вопрос работы с памятью подробнее, то можете обратиться к многочисленной доступной литературе. А заодно не забудьте покопаться в исходном коде ядра какой-нибудь ОС, например, Linux. Я не буду излагать здесь историю вычислительной техники, некоторые вещи не будут освещаться, а некоторые сильно упрощены.

Вольный перевод статьи gingearstudio.com/why-i-quit-my-dream-job-at-ubisoft от бывшего разработчика из Ubisoft.

Вступление

2005 год, я помню как начальство спросило меня, где я вижу себя через 10 лет, на что я ответил, что вижу себя в роли software-архитектора крупнейших AAA-класса гейм-проектов. Мечта стала реальностью буквально через несколько лет, когда я начал работать над проектом Assassin’s Creed Syndicate в роли, как вы уже догадались, software-архитектора. И вот, казалось бы, наконец, моя мечта быть причисленным к числу тех самых крутых, высокоуважаемых гейм-разработчиков, становится реальностью в процессе работы над престижнейшей игровой франшизой.

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

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

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

Frontend Guidelines

Правила и руководства оформления, форматирования HTML, СSS и JavaScript кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

От переводчика

Приветствую всех снова, меня зовут Максим Иванов, и сегодня я подготовил перевод, который, возможно, окажется для вас полезным. Бенджамин Де Кук (Benjamin De Cock), разработчик из Бельгии, собрал некоторые указания по оформлению кода, которые позиционируют себя как лучшие практики по написанию HTML, CSS, JS. Конечно, существует множество рекомендаций, например, есть хороший гайдлайн от Google, наверное, есть еще что-то, однако, если следовать хотя бы некоторым из них, то можно надеяться, что ваш код станет лучше. В отдельных случаях следование этим гайдлайнам не полезно, а совсем наоборот. В общем и целом, все зависит от вашего опыта и виденья дела, если вы новичок, то скорее вам будет полезно оценить то, что пишут другие и в обществе считается верным, если вы гуру, то наверное вам и не нужны гайдлайны, которые написаны непонятно кем на ваш взгляд. Итак, приступим.