На этой неделе мы снова делали приложения для Ассистента Google, обсуждали Google Pay и плохих дизайнеров, разрабатывали смешанную реальность и PWA, погружались в геймдизайн и маркетплейс продуктов. Все это и многое другое в нашем новом дайджесте!

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

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

Я не искал неприятностей. Не запускал процесс сборки Chrome тысячу раз за выходные, а только занимался самыми обычными задачами 21-го века — просто писал электронное письмо в 10:30 утра. И вдруг Gmail подвис. Я продолжал печатать несколько секунд, но на экране не появлялось никаких символов. Затем внезапно Gmail отвис — и я вернулся к своему очень важному письму. Но впоследствии всё повторилось, только на этот раз Gmail ещё дольше не отвечал запросы. Это странно…

Трудно устоять перед возможностью провести хорошее расследование, но в данном случае вызов особенно силён. Ведь я в Google работаю над улучшением производительности Chrome для Windows. Обнаружить причину зависания — моя работа. И после множества фальстартов и тяжёлых усилий мне всё-таки удалось выяснить, как Chrome, Gmail, Windows и наш IT-отдел вместе помешали мне набрать электронное письмо. По ходу дела нашёлся способ сэкономить значительное количество памяти для некоторых веб-страниц в Chrome.

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

СДСМ-15. Про QoS. Теперь с возможностью Pull Request'ов.

И вот мы дошли до темы QoS.

Знаете почему только сейчас и почему это будет закрывающая статья всего курса СДСМ? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.

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

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

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

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

Мы приходим к Заказчику и говорим ему: вот так мы будем планировать проект, вот так будем управлять изменениями, вот так будем управлять рисками, вот так будем проводить совещания, вот так будем эскалировать проблемы и принимать решения, вот такие сроки будут у нас на согласование, вот такая периодичность будет статусных совещаний и т.д. И приносим ему это в виде объемного документа этак страниц на 30-50 регламентирующего текста. Заказчик смотрит на это «широко закрытыми глазами» и говорит: «Круто!». То, что не соотносится с практикой, принятой у Заказчика, он предложит исправить, но в остальном документ будет принят.

А дальше началась жизнь и процессы прошли своим путем, принятия решений своим путем, а документ остался на полке. Иногда РП достает его чтобы показать, что Заказчик не соблюдает установленные сроки, либо нарушает другие договоренности. Но это делается, когда на проекте нарастает напряжение и сторонам нужно защищаться. Есть ситуации, когда РП пытается актуализировать процессы, но часто на него смотрят «косо» как на бюрократа, который вместо результата занимается «бумажками».

В итоге такой документ выполняет функцию защиты РП-ника или Подрядчика, либо маркетинговую функцию для Подрядчика: «Круто! Вы работаете по проектной технологии!». А хотелось бы, чтобы документ работал.

Под моим надзором примерно 1000 железных серверов, VPS даже не начинаю считать. Пару десятков из них обладают весьма критичными данными. И банальный ssh с ключами в стандартной ситуации не достаточно безопасен. Не все «кожаные люди» берегут ключи, поговорим как защититься от возможности потери ключа пользователем.

Всем привет!

Запускаем завтра курс «Проектирование UX/UI», что немного волнительно, т.к. второй не совсем программерский курс, да ещё и радикально отличающийся от такого же первого (Digital маркетинг). В общем ждём старта и первых отзывов от наших студентов, а пока что очередной понравившийся материал от наших преподавателей про персонажей.

Поехали.

Кратко: Персонажи — удобный инструмент для выполнения задач UX. Почему же они часто не помогают? Узнайте, какие подводные камни мешают персонажам быть полезными, и как их избегать.

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

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


Пример персонажа (Источник)

Доброго время суток. В статье рассказно о Material Design фреймворках для создания Web-страничек. Если вас интересует тема Material Design, также как и меня, то Добро пожаловать под кат, возможно, откроете для себя что-нибудь новое и интересное.

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

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

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

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

Я работаю, в основном, с Python/Django стеком, поэтому все примеры будут, в первую очередь, применительно к этому набору. Также ключевые технологии: Ubuntu (17.10), Python3 (3.6).

Содержание:

• Логи (logrotate)
• Демоны (systemd)
• локальные настройки

Фреймворк Bootstrap — это свободный набор инструментов для создания интерфейсов сайтов и веб-приложений. Его возможности ориентированы исключительно на фронтенд-разработку. Bootstrap — проект весьма популярный, о чём, например, говорит то, что он занимает (по состоянию на начало марта 2018-го года) второе место по количеству звёзд на GitHub.

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

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?

Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.

Здравствуйте, уважаемые читатели

Вот-вот в издательстве O'Reilly выйдет очередная занятная книжка с крокодилом


Этот увесистый компендиум всесторонне освещает вопросы о том, в какой степени сисадмин должен быть «network engineer», как оптимально соотносится автоматизация и программирование в работе такого специалиста. В книге даются основы Linux и Python, а также ожидается еще масса всего интересного.

Чтобы вам было интереснее участвовать в голосовании, предлагаем почитать небольшую статью одного из авторов (Джейсона Эдельмана), в которой он рассказывает, какие мысли подтолкнули его к сотрудничеству с Мэттом Освальтом и созданию этой книги

О чём статья

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

Дайте код!

X = np.array([ [0,0,1],[0,1,1],[1,0,1],[1,1,1] ])
y = np.array([[0,1,1,0]]).T
syn0 = 2*np.random.random((3,4)) - 1
syn1 = 2*np.random.random((4,1)) - 1
for j in xrange(60000):
    l1 = 1/(1+np.exp(-(np.dot(X,syn0))))
    l2 = 1/(1+np.exp(-(np.dot(l1,syn1))))
    l2_delta = (y - l2)*(l2*(1-l2))
    l1_delta = l2_delta.dot(syn1.T) * (l1 * (1-l1))
    syn1 += l1.T.dot(l2_delta)
    syn0 += X.T.dot(l1_delta)

Слишком сжато? Давайте разобьём его на более простые части.

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

Домашняя страница интерактивного руководства по стилю компании SEEK

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

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

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

Сколько себя помню, я всегда был одержим интерфейсами пользователя (UI). Помню, как наслаждался красотой Compaq TabWorks, пока играл в «The Incredible Machine» и слушал «Tears For Fears—Greatest Hits» на семейном компьютере.


Не осуждайте меня — я слушал «Mad World» ещё задолго до выхода «Донни Дарко» и этого страшного кролика. Если вы не узнали ни одну из этих отсылок, то возможно это потому, что я очень стар. Как сказал Джордж Костанза, «Дело не в тебе, а во мне».

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

По-настоящему я увлёкся UI, когда купил собственный компьютер. Я вступил в береговую охрану и сэкономил немного денег во время курса молодого бойца (когда нельзя было выходить в город из-за отжиманий и всего такого). Я хотел купить Chevy Cavalier (увы, но это не шутка), но мой отец предложил вместо этого потратить деньги на компьютер, поэтому я приобрёл в Office Depot собственный Compaq с Windows 98 в комплекте. Кроме того, Cavalier никак не купить за 800 баксов.

Windows 98

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


О, глубины моря! О, величественные рыбы! ДУХ ЗАХВАТЫВАЕТ.

Если бы я знал, с какими чудесами мне ещё предстоит встретиться. Если бы я только знал о Windows XP.

Эти советы, возможно, не все найдут полезными. Они адресованы тем, кому на работе бывает скучно. Так скучно, что уныние немного скрашивают лишь утренний контактик и послеобеденный ютубчик. Вот именно от них вам придется отказаться. Зачем? Сейчас узнаете.

Глеб Летушов, редактор-фрилансер, адаптировал для блога Нетологии чеклист с Github от David Dias. Этот чеклист уже переводили, но так как на Хабре его нет, мы решили, что он пригодится. В чеклисте собран полный список элементов, которые необходимо проверить перед запуском и публикацией сайта.



Список основан на многолетнем опыте фронтенд-разработчиков, а дополнения собраны из общедоступных источников.