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

Есть ряд принципов, которые нужно обязательно использовать при проектировании сайтов.

1. Оригинальные идеи. Именно идеи будут основой проектирования. Это самое важное, старт всего проекта. Очень важно не делать копии уже существующих проектов, почти всегда стоит задача сделать лучше, чем любой прямой или косвенный конкурент. Причем лучше на несколько порядков, иначе не получится переманить целевую аудиторию с тех сайтов, где она уже обитает. Идеи должен генерировать как проектировщик, так и инициатор проекта, тот самый носитель главной идеи.
   
   
2. Переносим оффлаин опыт. Один из важнейших принципов успешного проектирования – переносить опыт из оффлайна в онлайн. Нужно представить себя на месте представителя целевой аудитории, подумать, как он удовлетворяет свои потребности, связанные с тематикой проекта в оффлайне, и сделать то же самое, только лучше, в онлайне. Для иллюстрации принципа представим, что мы проектируем социальную сеть автолюбителей, где типичный представитель целевой аудитории имеет автомобиль, покупает автозапчасти в магазине возле дома, общается с приятелем Васей из соседнего гаража. Понимая поведение нашего потенциального пользователя в оффлайне, мы сразу можем предложить ему: привязать автомобиль к профилю по VIN-номеру с подробным справочником о нем; сделать некий аналог авторынка с разными продавцами, возможностью сравнивать цены, отзывами о работе; сообщество владельцев таких же автомобилей, с каждым из которых можно будет пообщаться и т.д. Это маленькие идеи, которые мне пришли в голову буквально на ходу, просто я представил себя на месте потенциального пользователя. Всего за пару минут можно сформировать несколько десятков неплохих, а самое главное полезных идей.
   
   

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

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

Многие рассказываю о проектировании: как пользоваться Axure или Sketch, какие функции должен содержать сайт, как правильно спроектировать страницу товара. Это все, безусловно, очень полезно, но не показывает полную картину происходящего в проектировании. В интернете даже нет ни одного полного примера технического задания на проекты такого уровня. На самом деле, чтобы спроектировать большой сайт, нужно потратить сотни часов на исследования, прототипирование и разработку подробного ТЗ. В этой статье я впервые в рунете покажу все этапы проектирования и результаты по ним, полный динамический прототип (более 150 прототипов) и большое ТЗ (более 200 страниц описания). Все это мы будем делать на примере проектирования аналога крупнейшей в мире E-commerce площадки «Alibaba.com».

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

Ключевой частью инженерии является любовь к тому, чтобы делать вещи, особенно к тому, чтобы делать их сразу же и делать их хорошо. Большая часть инженерии возникла из “tinkering” (aka “hacking”), добавив к этому желания «принципиального проектирования и создания», «целостности» и т. д. Все великие инженеры, которых я знаю лично, имеют глубокие моральные убеждения касательно того, что они делают, и почему это «должно быть сделано как можно лучше». Часть наложения темперамента на науку это своего рода «лабораторная крыса», которая наиболее счастлива, когда она в курсе эксперимента или создания нового экспериментального аппарата.

Пока за окном проходит месяц май, начинают распускаются цветы, играть гормоны и обостряться сезонные заболевания, в ведущих западных институтах тихо-мирно идёт научная работа и выходит много интереснейших книг. Тут можно найти практические пособия, профессиональные прогнозы, обработанные результаты последних исследований. И это не сухая академическая литература, а увлекательные произведения, которые рассчитаны на широкую аудиторию. От простого к сложному, на примере банальных вещей раскрываются сложные темы. Так как Хабр с MIT ещё не встретили друг друга и между ними не вспыхнула любовь с первого взгляда, вот подборка 14 книг из разных областей: от кибербезопасности и AI до исследований космоса. Весь список доступен по ссылке.

Хватит тратить время на скучные академические фолианты! Изучение Computer Science может быть веселым и увлекательным занятием.

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

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

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

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

Анимированные GIF’ы до сих пор часто используются в интернете. Хотя это древний формат, но даже в нём остаётся место для инноваций. На сайте Tumblr пополняется коллекция 3D GIF, в которых трёхмерный эффект создан путём простого добавления двух вертикальных белых линий. Странно, но такой простой трюк действительно работает, и без всяких 3D-очков.

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

У большинства из нас были отличные оценки по математике в школе и в универе. Помните, как мы решали примеры? Скажем, нужно взять производную от функции:

$$

Мы задумывались на несколько секунд и записывали готовый результат:

$$

Ученики послабее записывали решение по шагам и тратили существенно больше времени:

$$

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

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Перевод поста Стивена Вольфрама (Stephen Wolfram) "How to Teach Computational Thinking".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

— Вычислительное будущее
— Что такое вычислительное мышление?
— Знакомство с Wolfram Language
— А что насчет…
— Основы
— Куда может вписаться вычислительное мышление?
— Что дети могут делать?
— Во главе с детьми
— Что такое вычисления и программирование?
— Как все это будет происходить?

---

Вычислительное будущее

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

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

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

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

Здравствуйте! Сия статья представляет собой сказ о том, как я решил игру писать за 6 дней до Нового Года, о том, как я это сделал, с какими проблемами столкнулся и как их решил.

Перевод поста Стивена Вольфрама (Stephen Wolfram) "The Practical Business of Ontology: A Tale from the Front Lines".

Философия химических веществ

«Мы только должны решить: химикат — ближе к городу или к числу?» Я провел вчера свой день — как и большинство дней последних 30 лет — разрабатывая новые функции языка Wolfram. И вчера днем на одном из моих собраний была динамичная дискуссия о том, как расширить возможности языка в химии.

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

Попытался прокомментировать статью Ричард Хэмминг: Глава 28. Системная Инженерия» через свое понимание проблем «системной инженерии» и с учетом «современности», а также связанных или даже частично дублирующих ее EA \ BPM.

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

Системная инженерия или Systems engineering (SE) – также давно известное направление, как и BPM (Business Process Management) и EA (Enterprise Architecture). Найти, где заканчивается SE и начинаются ЕА и ВРМ – сложно. Уж очень все эти три направления «по-развивались», особенно в маркетинговой плоскости.

Любое проектирование «большого и сложного» — должно базироваться на SE. Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)

Визуальное и текстовое программирование

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

Исторически сложилось, что алгоритмы в программах записываются в виде исходных текстов. Почти никто не ставит под сомнение, что текст — это и есть лучшее средство представления алгоритмов. Алгоритм кодируется внутри функций на языке программирования, например, C или JavaScript. Для тех, кто хочет разобраться в алгоритме с высоты птичьего полёта, предусмотрен псевдокод. Однако с текстом есть серьезные проблемы. Дело в том, что человек не оптимизирован под сплошной текст. Человек оптимизирован на восприятие графики. Текст — это относительно новое изобретение, а вот графическую информацию организмы обрабатывают уже миллионы лет.

Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом — текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.

Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.

Как программировать на языке ДРАКОН

ДРАКОН не является самостоятельным языком программирования. Он работает в паре с

Сообщество жизненно важно любому проекту Open Source. Активное и живое сообщество явлется сердцем проекта. Однако, писать код под свободной лицензией не достаточно для привлечения пользователей и разработчиков к построению сообщества. В этой статье рассматривается то, что позволяет выстроить успешное сообщество OpenSource.

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

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

Что может быть лучшим подарком на день знаний для программиста? Конечно, полезная книга ;) Поэтому команда переводчиков «Pro Git» поднапряглась и доделала перевод книги на русский язык.

«Pro Git» — это довольно обширная обучающая книга о Git от Скотта Шакона — активного участника разработки проектов Git и GitHub. Автор рассматривает в тексте всевозможные аспекты работы с Git'ом, начиная с установки программы и базовых принципов работы децентрализованных систем контроля версий, и заканчивая рассмотрением внутреннего устройства Git'а и созданием валидных объектов в базе Git'а собственными руками. Несмотря на довольно обширный материал и затрагивание довольно специфических тем, книга написана довольно простым языком, содержит массу примеров и иллюстраций, и поэтому должна быть понятна и новичкам, только начинающим знакомиться с системами контроля версий.

Последняя версия перевода книги доступна в форматах pdf, epub, mobi.
Также доступна онлайн-версия перевода, но она, к сожалению, не обновлялась с мая.

Бизнес не любит:

1. 1С-Франчайзи, программистов 1С вообще, и почти все, что те делают;
2. веб-программистов и компании, создающие и продвигающие сайты, и все продукты их работы;
3. системы менеджмента качества и людей, которые занимаются их внедрением;
4. бухгалтеров и бух.учет;
5. экономистов со всеми их гигантскими экселевскими портянками;
6. внутренние проекты развития, на которые без слез уже смотреть невозможно;
7. Scrum и все эти доски, на которых неделями висят одни и те же стикеры;
8. ТОС, после внедрения которого дефицитов и неликвидов становится еще больше;
9. Контроллинг, который дает цифры позже, чем бух.учет;
10. KPI, адекватность которого приходится доказывать самому себе каждый раз, когда приносят эти цифры;
11. Системы мотивации, которые, как ни крути, «оклад+премия», хоть и названы модными словами, типа «грейд».

Продолжать можно до бесконечности. Никогда не задумывались, почему бизнес всего этого не любит? Или вообще не замечали, что бизнес этого не любит?

При этом, как ни странно, бизнес любит:

1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;