Я не настоящий сварщик и UX/UI не занимаюсь, но курсы проходил.
Что бы из этого я применил
1. Контраст — в темной теме мелкие буквы на темном фоне трудно читать. Вообще по устройству глаза палочки отвечают за различие светлого и темного, а колбочки за цвета. Общая структура страницы считывается по принципу светлый-темный, а подробности это цвет.
Один из тестов — попробуйте посмотреть страницу в оттенках серого. Все ли там будет читаемо?
2. Про использование множества цветов. Хитрый момент в том, что если мы возьмем модель HSL и возьмем разные цвета по H, то это будут действительно разные цвета и выглядеть будет пёстро. Но если мы рамках одного H меняем S и L, то это будут вариации одного цвета.
От себя рекомендую посмотреть блог Эрика Кеннеди на предмет UX/UI (Erik Kennedy).
В комментариях вспомнили кучу нюансов. Еще один нюанс — врагов можно на короткое время делать друзьями, хотят они этого или нет. Вот тут рассказывают о том, что время от времени дубы резко наращивают количество желудей, а белки не могут все съесть, поэтому запасают впрок и забывают про свои нычки.
Мой опыт использования этого стора пару лет назад:
1. Открываем я.стор
2. Вбиваем Angry Birds
3. Видим в выдаче что угодно со словами Angry и Birds.
4. Закрываем стор, я пытался.
Мой случай это примитивная СУБД, хранящая данные в JSON. И например там есть коллекции с ограничением «внешний ключ». При загрузке базы данных в память генерируется JSON Schema и проверяет всю базу на корректность. Причем там используется смешанный подход. Что-то через JSON Schema проверяется, что-то напрямую из данных. Некоторые виды проверок довольно муторно делать через JSON Schema.
А еще JSON Schema можно генерировать в рантайме, если например значения enum будут известны только на этапе выполнения программы. За счет этого схема станет строже.
Разделяю позицию автора про то что мы многое переусложняем.
Несколько мыслей по поводу сложности. У сложности есть разные причины и вот некоторые из них.
1. Сложность как следствие предметной области. Это самая честная сложность.
2. Сложность как следствие привычки. В эту ловушку я попал на своем пет проекте. Я его писал прям с нуля и со временем он оброс всякими вспомогательными штуками: системой локализации, тестами АПИ, системой валидации и др. И в какой-то момент мне нужно было сделать другой пет проект так же с нуля за ограниченное время. Ты уже привык к своей среде, а главная ценность время и нужно следовать ей.
А еще меня всегда поражали туториалы уровня Hello world!, где первая часть это настройка IDE, окружения, деплоя, прогона тестов. А вторая часть это Hello world! и все что настроено в первой части по большому счету не используется. Это можно рационально объяснить тем, что «хорошие привычки нужно прививать сразу». Но это не всегда возможно. В конце концов «На ошибках учатся. А некоторым вещам учатся только на ошибках.»
3. Сложность как следствие пессимизации задачи. По своему парадоксальное явление. Люди исходят из того, что не бывает простых задач. Бывают только сложные. И выбирают инструменты для сложных задач. Если бы это был осознанный выбор «на вырост» я бы понял. Но до «выроста» еще дожить надо. Это как: «Нам поручили спроектировать сортир на даче. Мы исходим из концепции хайлоад, поэтому будем дорабатывать проект туалета для молла в центре Москвы».
4. Сложность как следствие плохой структурированности. По большому счету нет разницы засунули ли вы 20 классов в один мегакласс или разложили по одному классу в 21 файл. Задача решается одна и та же тем же способом. Но развивать и поддерживать мегакласс сильно сложнее.
Борьба со сложностью начинается с вопросов «А зачем X нам? Что X дает?» Оказывается это очень непросто выбирать инструмент соразмерно задаче.
После почти трех лет работы в Азии компания попросила меня стать руководителем отдела международных отношений в конце 2012 года, в этой роли я отвечал за отношения Google с дипломатами, гражданским обществом и международными организациями, такими как ООН
1. То есть в течение многих лет человек занимал руководящую дипломатическую должность, но при этом ОТКРЫТО относился к одному из очень перспективных рынков «в одном поле стартап делать не сяду» из идеологических соображений.
2. Из текста я не понял, а какова была его обычная работа. При этом в тексте он явно говорит, про его действия ВНУТРИ компании.
Кабы он был внутренним идеологом, то тогда все сделанное было бы обоснованно.
А так, идеолог отвечает за внешнюю дипломатию. Почему же его работу пытаются саботировать?
До сих пор помню ту ярость, когда оказалось, что простейший сервер на node.js возвращающий «Hello, world!» пишется в 5 строчек, а в джаве это здоровенный сервлет + еще томкат развернуть не забудь и деплой собери и web.xml проверь…
До этого делал собственные мелкие проекты на джаве.
А еще это исчадие под названием мавен, которое «Мне надо скачать 200 Мб обновлений репозиториев ПРЯМО СЕЙЧАС, поэтому вот тебе стоп зе ворлд, пойди выпей чаю и съешь еще этих мягких французских булок»
Большая проблема тестов заключается в дороговизне их разработки и поддержки. Поскольку тест тесту рознь, то можно посмотреть на дешёвые виды тестирования.
К таковым я отношу:
1. Статический анализ. Несмотря на то, что eslint, вообще говоря, не про тестирование, он может выявлять ошибки вида «данной функции в этом контексте нету».
2. Smoke тесты. Да, ими много не натестируешь, но это намного лучше, чем ничего.
3. Развитие идеи snapshot тестов. Вот у нас есть «что-то», что требует тестирования. Нам нужно это сверить с «чем-то». Вопрос с чем?
Один из вариантов — у вас есть старая версия системы и новая. У вас есть внутри функция. На нее вы ставите перехватчик, который складывает в базу данных записи «функция на аргументы такие дала результат такой». Накопили результаты со старой версии и стали сверять с результатами перехватчика с той же функции в новой версии. Возможно у этого подхода уже есть свое умное название, но я не встречал.
Важная особенность рамды то, что она не мутирующая. Простой пример, array.sort() изменит массив. R.sort(comparator, array) создаст копию исходного массива и отсортирует его. Метод R.set так же создает копию объекта и изменяет значение по ключу. Плюсы и минусы понятны. Постоянное клонирование сказывается на производительности, но если вы видите вызов рамды, можете быть уверены, что исходные данные не будут испорчены побочным эффектом от мутирования.
Исходная задача бьется на две части — подготовка данных и формирование рисунков. Про формирование рисунков на R вопросов не было. Имея опыт работы с JavaScript, мне было проще выполнить подготовку данных на нем.
Потому что Measurelook и Jupyter notebook решают разные задачи. Задачи Measurelook перечислены в статье. Кроме того, сверхзадача Measurelook это хранение и распространение сырцов данных экспериментов. Возможность легко сравнивать результаты экспериментов с разных платформ. Jupyter notebook же: «The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text.» В мои задачи не входили живой код, печать уравнений, нарративные тексты и чтобы все это было красиво.
В связи с неизбежностью смерти автора и по мере нарастания связанных с этим проблем, я думаю, что сообщество открытого ПО дорастет до создания типовых завещаний по аналогии с лицензиями. Неудивительно, что код будет жить дольше, чем его создатели.
Здравствуйте!
Local storage имеет смысл только в оффлайн режиме. Можно сделать дистрибутив на основе MEAN и получить взамен необходимость поддерживать дистрибутивы под разные платформы, объяснять пользователю как с этим работать, разбираться с проблемами «почему у меня не запустилось?» У части пользователей не запустится и они молча уйдут. И все это ради local storage.
Я наоборот считаю, что отсутствие local storage провоцирует иметь несколько копий одной и той же базы, а значит получаются естественные бекапы. Дата сохранения базы ставится автоматически, так что всегда можно понять какие из них старые, а какие новые.
А какие-нибудь онлайн концерты за деньги еще не придумали?
А про поддержку музыкантов — даже на ютубе полно музыкантов без патреона. Хотя казалось бы.
Что бы из этого я применил
1. Контраст — в темной теме мелкие буквы на темном фоне трудно читать. Вообще по устройству глаза палочки отвечают за различие светлого и темного, а колбочки за цвета. Общая структура страницы считывается по принципу светлый-темный, а подробности это цвет.
Один из тестов — попробуйте посмотреть страницу в оттенках серого. Все ли там будет читаемо?
2. Про использование множества цветов. Хитрый момент в том, что если мы возьмем модель HSL и возьмем разные цвета по H, то это будут действительно разные цвета и выглядеть будет пёстро. Но если мы рамках одного H меняем S и L, то это будут вариации одного цвета.
От себя рекомендую посмотреть блог Эрика Кеннеди на предмет UX/UI (Erik Kennedy).
1. Открываем я.стор
2. Вбиваем Angry Birds
3. Видим в выдаче что угодно со словами Angry и Birds.
4. Закрываем стор, я пытался.
Несколько мыслей по поводу сложности. У сложности есть разные причины и вот некоторые из них.
1. Сложность как следствие предметной области. Это самая честная сложность.
2. Сложность как следствие привычки. В эту ловушку я попал на своем пет проекте. Я его писал прям с нуля и со временем он оброс всякими вспомогательными штуками: системой локализации, тестами АПИ, системой валидации и др. И в какой-то момент мне нужно было сделать другой пет проект так же с нуля за ограниченное время. Ты уже привык к своей среде, а главная ценность время и нужно следовать ей.
А еще меня всегда поражали туториалы уровня Hello world!, где первая часть это настройка IDE, окружения, деплоя, прогона тестов. А вторая часть это Hello world! и все что настроено в первой части по большому счету не используется. Это можно рационально объяснить тем, что «хорошие привычки нужно прививать сразу». Но это не всегда возможно. В конце концов «На ошибках учатся. А некоторым вещам учатся только на ошибках.»
3. Сложность как следствие пессимизации задачи. По своему парадоксальное явление. Люди исходят из того, что не бывает простых задач. Бывают только сложные. И выбирают инструменты для сложных задач. Если бы это был осознанный выбор «на вырост» я бы понял. Но до «выроста» еще дожить надо. Это как: «Нам поручили спроектировать сортир на даче. Мы исходим из концепции хайлоад, поэтому будем дорабатывать проект туалета для молла в центре Москвы».
4. Сложность как следствие плохой структурированности. По большому счету нет разницы засунули ли вы 20 классов в один мегакласс или разложили по одному классу в 21 файл. Задача решается одна и та же тем же способом. Но развивать и поддерживать мегакласс сильно сложнее.
Борьба со сложностью начинается с вопросов «А зачем X нам? Что X дает?» Оказывается это очень непросто выбирать инструмент соразмерно задаче.
1. То есть в течение многих лет человек занимал руководящую дипломатическую должность, но при этом ОТКРЫТО относился к одному из очень перспективных рынков «в одном поле стартап делать не сяду» из идеологических соображений.
2. Из текста я не понял, а какова была его обычная работа. При этом в тексте он явно говорит, про его действия ВНУТРИ компании.
Кабы он был внутренним идеологом, то тогда все сделанное было бы обоснованно.
А так, идеолог отвечает за внешнюю дипломатию. Почему же его работу пытаются саботировать?
До этого делал собственные мелкие проекты на джаве.
А еще это исчадие под названием мавен, которое «Мне надо скачать 200 Мб обновлений репозиториев ПРЯМО СЕЙЧАС, поэтому вот тебе стоп зе ворлд, пойди выпей чаю и съешь еще этих мягких французских булок»
К таковым я отношу:
1. Статический анализ. Несмотря на то, что eslint, вообще говоря, не про тестирование, он может выявлять ошибки вида «данной функции в этом контексте нету».
2. Smoke тесты. Да, ими много не натестируешь, но это намного лучше, чем ничего.
3. Развитие идеи snapshot тестов. Вот у нас есть «что-то», что требует тестирования. Нам нужно это сверить с «чем-то». Вопрос с чем?
Один из вариантов — у вас есть старая версия системы и новая. У вас есть внутри функция. На нее вы ставите перехватчик, который складывает в базу данных записи «функция на аргументы такие дала результат такой». Накопили результаты со старой версии и стали сверять с результатами перехватчика с той же функции в новой версии. Возможно у этого подхода уже есть свое умное название, но я не встречал.
Local storage имеет смысл только в оффлайн режиме. Можно сделать дистрибутив на основе MEAN и получить взамен необходимость поддерживать дистрибутивы под разные платформы, объяснять пользователю как с этим работать, разбираться с проблемами «почему у меня не запустилось?» У части пользователей не запустится и они молча уйдут. И все это ради local storage.
Я наоборот считаю, что отсутствие local storage провоцирует иметь несколько копий одной и той же базы, а значит получаются естественные бекапы. Дата сохранения базы ставится автоматически, так что всегда можно понять какие из них старые, а какие новые.