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

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

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

Легко опустить руки и сказать: «Я никогда не смогу сделать это должным образом, я не художник!», Но, оказывается, есть уйма ловких приёмов, которые вы сможете использовать, чтобы поднять свою работу на другой уровень, не имея опыта в графическом дизайне.

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

1. Для создания иерархии используем цвет и вес вместо размера

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

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

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

Продолжаем рассказывать историю Atlassian. 1 часть вы можете прочитать тут.

2015 год — настоящее время: расширение на прибыльные конкурентные рынки

Для многих SaaS-компаний сегодняшний бизнес Atlassian выглядит как «конечная цель»: вырасти в огромную работающую на мировом рынке публичную компанию со сложным набором интегрированных продуктов для самых разных команд.

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

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

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

Переведено в Alconost

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

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

Привет, Хабр! По традиции, представляем вашему вниманию дюжину рецензий на научные статьи от членов сообщества Open Data Science из канала #article_essense. Хотите получать их раньше всех — вступайте в сообщество ODS!

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

Статьи на сегодня:

Как создать чистый интерфейс, используя всего лишь один цвет? Вы узнаете из этой статьи. Перевод «Я люблю ИП».

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

У меня есть другое мнение на этот счёт: теория цвета бесполезна.

Но если теория цвета не является прочной основой для выбора цвета в дизайне интерфейсов, то что тогда является?

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

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

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

Вы готовы? Тогда поехали.

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

В двух словах:

1. Пакет можно использовать для тестирования сайтов.
2. Пакет можно использовать для парсинга данных.
3. Пакет можно использовать для автоматизации ввода данных на сайты.

Альтернативы:

Casper.js, phantom.js, watir и много кто еще, в гугле полно всех и вся. Почему я за nightmare.js:

1. Простота использования.
2. Полная поддержка html5, никаких конфликтов с сайтами.
3. Расширяемый через экшены.

Структура библиотеки

Nightmare класс использует фреймворк electron, для каждой страницы создавая объект (BrowserWindow) который запускает браузер оболочку Chromium.

Принцип работы

1. Nightmare инициализирует новое приложение electron с стартовой страницей, которую необходимо подвергнуть дальнейшей обработке.
2. Перед загрузкой исследуемой страницы загружаются скрипты, которые позволяют поддерживать двустороннее взаимодействие программиста и страницы через серию эмиттеров.
3. Nightmare предоставляет программисту набор апи (цепочки действий), позволяющие произвести любые манипуляции с сайтом и получить требуемые данные.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью 2014 года прошла новая серия лекций ведущих предпринимателей и экспертов Y Combinator:

Мы продолжаем публиковать в блоге ФРИИ материалы нового формата — для того, чтобы сравнить подходы к развитию стартапов в США и России мы устраиваем перекрестные интервью, в ходе которых на одни и те же вопросы отвечают знаменитые предприниматели, инвесторы и ИТ-эксперты двух стран.

В первом выпуске о причинах успеха и провала стартапов рассуждали Пол Грэм (Y Combinator) и Дмитрий Калаев (Акселератор ФРИИ). В сегодняшнем материале тему «бережливого» подхода к созданию стартапов обсудят автор книги Lean Startup Эрик Рис и инвестиционный менеджер ФРИИ Илья Королев ilyakorolev.

Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью 2014 года прошла новая серия лекций ведущих предпринимателей и экспертов Y Combinator:

Пролог

Эта история началась более трех лет назад. Наша небольшая компания DAVA стала частью Wargaming, и мы начали обдумывать, какие проекты делать дальше. Чтобы напомнить, каким был мобайл три года назад, скажу, что тогда не было ни Clash Of Clans, ни Puzzle & Dragons, ни многих очень известных сегодня проектов. Mid-core тогда только-только начинался. Рынок был в разы меньше сегодняшнего.

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

Тогда в разработке у нас находилось несколько игр. Одна из них носила рабочее название «Sniper». Основной геймплей-идеей была стрельба в снайперском режиме из стоящего в обороне танка, по другим танкам, которыми управлял AI и которые могли атаковать в ответ.

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

С этого все и началось!

Когда мы начинали разработку “Снайпера”, то рассматривали технологии, которые тогда были доступны для мобильных платформ. На тот момент Unity был еще на достаточно ранней стадии своего развития: по сути, необходимых нам технологий еще не было.

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

Также мы понимали, что на C# мы не сможем выжать максимум из устройств, под которые мы разрабатываем, и всегда будем ограничены.
Unreal Engine 3 тоже не подходил по ряду похожих причин.

В итоге, мы решили дорабатывать свой движок!

*Эта статья впервые была опубликована в журнале Forbes от 27 Июня 2014 года. На Хабре публикуется её полная версия.

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

Я помню как играл первый раз в Цезарь 3, это удивительно умная и сбалансированная игра, создает чувство, что город живет своей жизнью и после завершения миссии. Можно провести часы, наблюдая за городом и не вмешиваться в его жизнь: плебеи будут бегать по городу в поисках работы, а патриции жаловаться на неважные условия жизни, торговцы, школьники, лодки, жрецы — этот мир замирает лишь в минуты пауз, давая игроку возможность продумать следующий шаг. Исследуя внутренние алгоритмы игры, я не перестаю удивляться с какой точностью авторы сложили кусочки мозаики, под названием «баланс». За время, проведенное над восстановлением кода оригинальной игры скопилось достаточно материала по макромеханике игры, которым я хочу поделиться с хабрасообществом.

Вступление

Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.

Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.

Думаю все заметили, что сейчас стало появляться множество всяких бродилок с выживанием в стиле Minecraft. Сделать такую решился и я. Начало было лёгким — Unity3d имеет огромный функционал для сознания простеньких игр (и не только). Персонаж, игровые объекты, в общем основу сделать быстро. Но какой minecraft без рандомно генерируемого мира? Это стало первой трудной задачей. И думаю не только для меня. Просмотрев весь гугл и потратив кучу времени на эту бесполезную вещь я решил написать эту статью дабы сократить страдания других.

Давайте попробуем посмотреть на Sweet.js, компилятор, который реализует гигиенические макросы для JavaScript.

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

Sweet.js оперирует своим собственным форматом синтаксического дерева, почти на уровне токенов, с минимальной структурой. С одной стороны это делает возможным определять довольно экзотические синтаксисы для своих макросов, с другой — делает написание макросов несколько сложнее, как если бы они были определены над стандартным AST JavaScript.

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.