Думается, у большинства из тех, кто посчитал после первых неудачных попыток, что у них руки «не из того места», просто недостаточно тренировки — карандаш (и прочие кисти/мелки...) это такой-же инструмент для выражения задуманного, который нужно научиться использовать. И да — куда сложнее «второе» («знать куда надо»), да еще так (уже «третье», наверное), чтобы другие поняли — что художник хотел передать или почувствовать то-же, что чувствовал автор. Это третье — работа не только автора, но и зрителя — мне, например, минут десять нужно постоять, глядя на картину, чтобы хоть как-то начать ее воспринимать — трудно понять, как с этим справляются посетители музеев, буквально пробегая взглядом по картинам.
Мне посчастливилось пару лет назад в национальный музей в Амстердаме попасть — провел там семь часов (до закрытия), посмотрев только произведения, описанные в аудиогиде (музей и виртуально можно посетить).
В принципе — не «туториал», а скорее «гайд», подобный упомянутому выше (конечно с большими деталями) — вполне может иметь смысл, но в определенном контексте. Например, если я правильно помню, изначально Дисней рисовал персонажей сам, позже — уже нанимал художников (продолжая их обучение, отправляя на лето загород рисовать живую натуру, животных, птиц — не мультяшных), и этим художникам набрасывал основные детали сцены или персонажа (типа картинки №1, чаще, конечно, больше деталей, пример) — поза, направление головы, и т.п., а художники завершали сцену в соответствии со стилем. Для общения на таком уровне — нужно иметь общее видение, понимание что имелось ввиду — как в парном программировании (или когда команда давно программирует вместе, без специализаций внутри). И то, что для постороннего взгляда такие «гайды» не имеют смысла — это вполне объяснимо. Другой пример (отсюда).
Сам я в юности много рисовал — самоучкой, копируя с газетных карикатур, из одолженных на пару дней книг Бидструпа и истории студии Диснея, но главное ежедневно рисуя.
Спустя 30 лет — с удовольствием прошел курс по рисованию на Udemy. В нем, кстати, люди постоянно выкладывают свои рисунки для каждого урока — думаю помогает уменьшить страх критики, видя, что у всех получается по разному.
И мне Ваша статья/публикация интересна.
Печатаю на RepRapPro (купленном в 2013, стоил как самолёт — 600 евро вроде, плюс растаможка) — который собран из 8мм прутков с резьбой. Пару лет назад закрыл его под икеевский столик с акрильными боковинами (как Пруса показывает https://youtu.be/oS7ZtBNh2hE ), только резиновый уплотнитель вдоль щелей дверцы поставил — стало тише, температура внутри до 35 градусов поднимается при печати, и пыль на принтер больше не летит. И красиво — свет внутри, акрил с картинкой типа изморози.
Принтер давно подключён к малинке — печатаю через OctoPrint, через браузер (в том числе вебкамера картинку может транслировать), в том числе можно с телефона и планшета за прогрессом следить или управлять.
Стекло на подогреваемом столе (которое кладётся на алюминиевую пластину) заменил на недорогой магнитный мат — удобно снимать, хорошая адгезия (для PLA во всяком случае).
Добавил свой напечатанный обдув, конечно.
Прошивки не менял, механику не менял и не настраивал. Печатаю в основном механические детали (для хобби) — качество так себе, но мне достаточно для прототипов.
Из программ: изначально пробовал SketchUp — легко осваивается, часто были проблемы с печатью его геометрии; потом Blender — осваивается дольше и больше подходит для творческий моделей, где дизайнишь полигонами; потом нашёл PTC Modeling Express https://www.ptc.com/en/products/creo/elements-direct/modeling-express
быстрый в освоении и очень удобный для создания механических узлов и деталей, но он только под Windows и редко обновляется, пришлось освоить Autodesk Fusion 360 — практически аналог, но с бОльшими возможностями (за счёт его частого обновления, наверное), хотя мне показался более сложным в освоении; TinkerCad — простой, но ограничен настолько, что я больше тратил времени на найти способ как сделать в нем что-то, что элементарно делается в Express modeling или Fusion.
Есть страны, где совместное проживание, без регистрации брака — законно приравнивается к официальному браку (включая право на приобретаемое имущество). Из преимуществ — не нужно ждать месяцами (и годами) развода, вот и не видят смысл оформлять.
Возможно, я — точно никогда больше его не использовал. В Википедии указано про последнюю стабильную версию Майкрософт макро ассемблера, выпущенную в 2017, вероятно кто-то все-же им пользуется.
Я прочитал первые абзацы, пробежал по остальным, внимательно начал читать комментарии, откуда и понял, что это «вредные советы». Я сделал это так, поскольку
Я многократно слышал мнение, подобное изложенному, но высказанное вполне серьезно
Не думаю, что мой комментарий можно расценивать как «гневный», и я не считаю, что автор не прав — я читаю, что возможны вариации в понимании идеи статьи.
К сожалению не очевидно, что статья в стиле «вредные советы» (на теги под статьей вообще редко смотрю).
Я многократно слышал мнение, подобное изложенному, но высказанное вполне серьезно, в том числе от хороших разработчиков с 10-15 лет стажа — они просто не умели использовать тесты, и не хотели этому учиться.
Впечатление, что под «программистом» или «программированием» здесь имеется ввиду такой же широкий смысл как “компьютерщик”.
Для одних задач — нужно изучить фреймворк/язык, следуя готовым гайдлайнам и решениям, для других — использовать логику (например метод «чёрного ящика» при хотфиксе легаси-кода), для третьих — аналитику (перекладывая бизнес-домен на программные модели), работа с машинным обучением, криптографией, встроенными системами, PLC, 3D графика и игры, архитекторы и тимлиды… Да и над одной и той же задачей разные программисты работают по разному.
Это хорошо, что у школьников есть возможность изучать программирование, это однозначно помогает тем, кто в дальнейшем программирует. Однако подозреваю, что умение написать спагетти-код (с переменными a1,a2) и потом мучительно его отлаживать (без использования отладчика) — может задействовать разные области мозга, по сравнению с написанием хорошо структурированной программы, разбитой на логические модули, отражающие одну из метафор бизнес-модели?
Я написал на ассемблере небольшой графический редактор для десятикадровой анимации — 3kB исполняемый com-файла (на Поиске, на компиляцию программ на «С» в нем памяти не хватало — с одной платой расширения ), не используя макросы macro-assembler-a, так что думаю осмысленно звучит «ассемблер» без «макро», разве что не эффективно так программы писать на asm-е. 21е прерывание (DOS подпрограммы) даже вроде не использовал — только 10е и 16е. Потом осознал, что не нужно выпендриваться — с макросами проще и быстрее.
Помню, нарисовал в этом редакторе переливающуюся надпись “T2 terminator 2”, вышедшего за год то этого фильма (по-пиксельно, без мыши).
Похожий контент про С на NDC был представлен https://youtu.be/xGVRF-Y--hI
Мы добавили в свой PaaS поддержку BlobFuse Flex volume. Едва анонсировали для пользователей — появилось слово deprecated” в git репозитории к этому драйверу, как альтернатива — объявлен CSI драйвер (и только он будет поддерживаться с k8s 1.21), который “preview, not for production” сейчас, и “мы не уверены, что депрекейтед BlobFuse Flex volume поддерживается Майкрософтом” (смысл ответа на запрос к MS «что теперь делать?»).
И такое не редко. Наверное в современном мире успешнее не те, кто «старше, значит опытнее», а скорее те, кто «опытнее, значит более динамичные и гибкие» (это я о нас — тех, кто все эти компоненты и фреймворки использует).
Согласен, выглядит очень затратно. Я не оправдываю этого, сам участвовал в проектах, неоправданно раздутых и затянутых. Но бывают и оправданно большие и ресурсоемкие проекты.
Просто из любопытства попробовал прикинуть — что требовалось сделать в клиенте (фактически “с нуля”, но используя готовый опыт), посмотрев ролик о клиенте на ютубе.
Здесь примерный список функциональности, видимой клиенту
(формы и опции)
Регистрация
— общая
— телефон
— Фейсбук
— Пароль
— Восстановление пароля
Список платежей с деталями
Список поездок с деталями
Free rides (не знаю что это)
Помощь
— иерархическая структура
— Последняя поездка, Квитанция
— Репорт проблем
Настройки
Форма платежей
— настройка и платёж картами
— Настройка и платёж PayPal
— Настройка и использование rewards, promo,gift
Профиль
— персональный
— Бизнес
— Семейный (платить за них и отслеживать поездки)
— Фавориты
Карта и поездка
— доступные машины вокруг (также отрисовка машин, изменение их положения и статуса)
— История остановок недалеко (?)
— Ввод пунктов посадки высадки
— История пунктов
— Известные места (дом, работа)
— Выбор типа машины (эконом, taxi, SUV и т.д.) с деталями
— Выбор «приватный», «бизнес»,«семейный» (немало логики за этим)
— Вызов машины
— Отмена поездки
— Стоимость поездки
— Детали машины, водителя
— Контакт с водителем — звонок, сообщение, выбор своего номера телефона
— Share status (примерное время прибытия в пункт назначения)
— Разделить с другом оплату
— Построение примерного маршрута
— Отслеживание на карте поездки
— Оплата поездки
— Оценка водителя
— Квитанция
— Многие эти формы должны работать асинхронно, также информация в них синхронизируется
— изменение внешние — окружение, машина, водитель, поездка
— внутренние — детали профиля, изменение с другого клиента (например клиент на другом телефоне)
— Данные не теряются и синхронизируются при потери сети, кэширование для уменьшения трафика и отзывчивости
— Атрибуты качества. Например — отзывчивость форм в пределах заданного интервала,
— Согласованность дизайна и поведения форм
— Количество сбоев (такое тоже есть) и восстанавливаемость (recovery)
— Юнит-тесты
Все это нужно
— обединять (merge — наработки разных итераций спринтов, разных команд, багфиксы)
— интегрировать — разные компоненты (возможно разных команд) взаимодействуют друг с другом и с сервером
— тестировать (в том числе на различных моделях телефонов и версиях iOS, iPadOS)
— билдить
— деплоить
— исправлять баги
— расширять функциональность
и повторять все циклы снова.
Не забываем о необходимости согласований и коммуникации такого количества команд и разработчиков (а среди них — решение проблемы модели, предложенной братьями Дрейфус). Снова вспомним о книге «Мифический человеко-месяц», и главе «Человеко-месяц» из нее — о том, как количество вовлекаемых в решение задачи человек, влияет на общую производительность в проекте.
Также на все это накладываются ограничения библиотек и их версий (а это хаки и воркэраунды) — просто “не паханная и необъятная целина” (без намека на оценку затрат или даже guesstimates).
Чистка легаси решений — даже в свежем коде: то, что казалось на прошлой неделе хорошим или приемлемым решением — оказывается неудачным (люди учатся, повышают свою квалификацию), архитектор на ревью выявил проблемы дизайна
Поддержание приемлемой производительности компонент и связей.
Примерно так отличается программа от коммерческого продукта.
Вполне обычные ощущения, возникающие у большинства разработчиков, пришедших в новый проект (пока не узнает деталей). Иногда эти ощущения даже верные. Это как посмотреть на прохождение квеста — «все же просто», вместо того, чтобы пройти его. Отсюда и появляется такое популярное в кругу разработчиков желание «переписать с нуля». Я такое много раз видел.
Были разговоры, что Netscape потерял рынок браузеров, когда его было решено переписать в пятой версии (как обычно — мотив для этого был).
Также стоит вспомнить главу «Эффект второй системы» из книги «Мифический человеко-месяц» (с ее публикации в 1975 году ничего не изменилось):
Эта вторая система — самая опасная для человека, который ее проектирует. Когда он трудится над своей третьей и более поздними, все экземпляры из его предшествующего опыта будут подтверждать друг друга относительно общих характеристик таких систем, и их различия будут определять те части его опыта, которые являются частными и необобщаемыми.
Общая тенденция — делать дизайн второй системы с большим за- пасом, используя все идеи и излишества, которые были осторожно отклонены в первой. В результате, как говорил Овидий, получается «большая куча».
На днях нашел на Амазоне переведенную версию Астровитянки, выпущенную Николаем Горькавым (AstroNikki), по цене 10 долларов (значительно ниже обычных цен на книги на Амазоне). Как я понял, перед этим он очень маленький «тираж» напечатал, чтобы получить отзыв, наверное (видел такую книгу за сотню долларов продают).
Мне посчастливилось пару лет назад в национальный музей в Амстердаме попасть — провел там семь часов (до закрытия), посмотрев только произведения, описанные в аудиогиде (музей и виртуально можно посетить).
Сам я в юности много рисовал — самоучкой, копируя с газетных карикатур, из одолженных на пару дней книг Бидструпа и истории студии Диснея, но главное ежедневно рисуя.
Спустя 30 лет — с удовольствием прошел курс по рисованию на Udemy. В нем, кстати, люди постоянно выкладывают свои рисунки для каждого урока — думаю помогает уменьшить страх критики, видя, что у всех получается по разному.
И мне Ваша статья/публикация интересна.
Вспомнилась статья (или правильно говорить пост, публикация?)
https://habr.com/ru/post/410001/
Да, с такими инструментами приятно работать.
Это верно, хотя некоторые использую принтер чтобы облегчить некоторые задачи строительства — например:
https://youtu.be/JW1x9uVllyk
Печатаю на RepRapPro (купленном в 2013, стоил как самолёт — 600 евро вроде, плюс растаможка) — который собран из 8мм прутков с резьбой. Пару лет назад закрыл его под икеевский столик с акрильными боковинами (как Пруса показывает https://youtu.be/oS7ZtBNh2hE ), только резиновый уплотнитель вдоль щелей дверцы поставил — стало тише, температура внутри до 35 градусов поднимается при печати, и пыль на принтер больше не летит. И красиво — свет внутри, акрил с картинкой типа изморози.
Принтер давно подключён к малинке — печатаю через OctoPrint, через браузер (в том числе вебкамера картинку может транслировать), в том числе можно с телефона и планшета за прогрессом следить или управлять.
Стекло на подогреваемом столе (которое кладётся на алюминиевую пластину) заменил на недорогой магнитный мат — удобно снимать, хорошая адгезия (для PLA во всяком случае).
Добавил свой напечатанный обдув, конечно.
Прошивки не менял, механику не менял и не настраивал. Печатаю в основном механические детали (для хобби) — качество так себе, но мне достаточно для прототипов.
Из программ: изначально пробовал SketchUp — легко осваивается, часто были проблемы с печатью его геометрии; потом Blender — осваивается дольше и больше подходит для творческий моделей, где дизайнишь полигонами; потом нашёл PTC Modeling Express
https://www.ptc.com/en/products/creo/elements-direct/modeling-express
быстрый в освоении и очень удобный для создания механических узлов и деталей, но он только под Windows и редко обновляется, пришлось освоить Autodesk Fusion 360 — практически аналог, но с бОльшими возможностями (за счёт его частого обновления, наверное), хотя мне показался более сложным в освоении; TinkerCad — простой, но ограничен настолько, что я больше тратил времени на найти способ как сделать в нем что-то, что элементарно делается в Express modeling или Fusion.
Клипером не пользуюсь, но принтер давно к малине подключён — через OctoPrint печатаю, очень удобно.
Возможно, я — точно никогда больше его не использовал. В Википедии указано про последнюю стабильную версию Майкрософт макро ассемблера, выпущенную в 2017, вероятно кто-то все-же им пользуется.
Не думаю, что мой комментарий можно расценивать как «гневный», и я не считаю, что автор не прав — я читаю, что возможны вариации в понимании идеи статьи.
Я многократно слышал мнение, подобное изложенному, но высказанное вполне серьезно, в том числе от хороших разработчиков с 10-15 лет стажа — они просто не умели использовать тесты, и не хотели этому учиться.
Впечатление, что под «программистом» или «программированием» здесь имеется ввиду такой же широкий смысл как “компьютерщик”.
Для одних задач — нужно изучить фреймворк/язык, следуя готовым гайдлайнам и решениям, для других — использовать логику (например метод «чёрного ящика» при хотфиксе легаси-кода), для третьих — аналитику (перекладывая бизнес-домен на программные модели), работа с машинным обучением, криптографией, встроенными системами, PLC, 3D графика и игры, архитекторы и тимлиды… Да и над одной и той же задачей разные программисты работают по разному.
Это хорошо, что у школьников есть возможность изучать программирование, это однозначно помогает тем, кто в дальнейшем программирует. Однако подозреваю, что умение написать спагетти-код (с переменными a1,a2) и потом мучительно его отлаживать (без использования отладчика) — может задействовать разные области мозга, по сравнению с написанием хорошо структурированной программы, разбитой на логические модули, отражающие одну из метафор бизнес-модели?
Я написал на ассемблере небольшой графический редактор для десятикадровой анимации — 3kB исполняемый com-файла (на Поиске, на компиляцию программ на «С» в нем памяти не хватало — с одной платой расширения ), не используя макросы macro-assembler-a, так что думаю осмысленно звучит «ассемблер» без «макро», разве что не эффективно так программы писать на asm-е. 21е прерывание (DOS подпрограммы) даже вроде не использовал — только 10е и 16е. Потом осознал, что не нужно выпендриваться — с макросами проще и быстрее.
Помню, нарисовал в этом редакторе переливающуюся надпись “T2 terminator 2”, вышедшего за год то этого фильма (по-пиксельно, без мыши).
Похожий контент про С на NDC был представлен
https://youtu.be/xGVRF-Y--hI
Мы добавили в свой PaaS поддержку BlobFuse Flex volume. Едва анонсировали для пользователей — появилось слово deprecated” в git репозитории к этому драйверу, как альтернатива — объявлен CSI драйвер (и только он будет поддерживаться с k8s 1.21), который “preview, not for production” сейчас, и “мы не уверены, что депрекейтед BlobFuse Flex volume поддерживается Майкрософтом” (смысл ответа на запрос к MS «что теперь делать?»).
И такое не редко. Наверное в современном мире успешнее не те, кто «старше, значит опытнее», а скорее те, кто «опытнее, значит более динамичные и гибкие» (это я о нас — тех, кто все эти компоненты и фреймворки использует).
Просто из любопытства попробовал прикинуть — что требовалось сделать в клиенте (фактически “с нуля”, но используя готовый опыт), посмотрев ролик о клиенте на ютубе.
Здесь примерный список функциональности, видимой клиенту
— общая
— телефон
— Фейсбук
— Пароль
— Восстановление пароля
Список платежей с деталями
Список поездок с деталями
Free rides (не знаю что это)
Помощь
— иерархическая структура
— Последняя поездка, Квитанция
— Репорт проблем
Настройки
Форма платежей
— настройка и платёж картами
— Настройка и платёж PayPal
— Настройка и использование rewards, promo,gift
Профиль
— персональный
— Бизнес
— Семейный (платить за них и отслеживать поездки)
— Фавориты
Карта и поездка
— доступные машины вокруг (также отрисовка машин, изменение их положения и статуса)
— История остановок недалеко (?)
— Ввод пунктов посадки высадки
— История пунктов
— Известные места (дом, работа)
— Выбор типа машины (эконом, taxi, SUV и т.д.) с деталями
— Выбор «приватный», «бизнес»,«семейный» (немало логики за этим)
— Вызов машины
— Отмена поездки
— Стоимость поездки
— Детали машины, водителя
— Контакт с водителем — звонок, сообщение, выбор своего номера телефона
— Share status (примерное время прибытия в пункт назначения)
— Разделить с другом оплату
— Построение примерного маршрута
— Отслеживание на карте поездки
— Оплата поездки
— Оценка водителя
— Квитанция
Это только для пассажира — без функций водителя.
Нужно помнить также о нефункциональных требованиях,
— изменение внешние — окружение, машина, водитель, поездка
— внутренние — детали профиля, изменение с другого клиента (например клиент на другом телефоне)
— Данные не теряются и синхронизируются при потери сети, кэширование для уменьшения трафика и отзывчивости
— Атрибуты качества. Например — отзывчивость форм в пределах заданного интервала,
— Согласованность дизайна и поведения форм
— Количество сбоев (такое тоже есть) и восстанавливаемость (recovery)
— Юнит-тесты
Все это нужно
— обединять (merge — наработки разных итераций спринтов, разных команд, багфиксы)
— интегрировать — разные компоненты (возможно разных команд) взаимодействуют друг с другом и с сервером
— тестировать (в том числе на различных моделях телефонов и версиях iOS, iPadOS)
— билдить
— деплоить
— исправлять баги
— расширять функциональность
и повторять все циклы снова.
Не забываем о необходимости согласований и коммуникации такого количества команд и разработчиков (а среди них — решение проблемы модели, предложенной братьями Дрейфус). Снова вспомним о книге «Мифический человеко-месяц», и главе «Человеко-месяц» из нее — о том, как количество вовлекаемых в решение задачи человек, влияет на общую производительность в проекте.
Также на все это накладываются ограничения библиотек и их версий (а это хаки и воркэраунды) — просто “не паханная и необъятная целина” (без намека на оценку затрат или даже guesstimates).
Чистка легаси решений — даже в свежем коде: то, что казалось на прошлой неделе хорошим или приемлемым решением — оказывается неудачным (люди учатся, повышают свою квалификацию), архитектор на ревью выявил проблемы дизайна
Поддержание приемлемой производительности компонент и связей.
Примерно так отличается программа от коммерческого продукта.
В общем — я люблю свою работу.
Были разговоры, что Netscape потерял рынок браузеров, когда его было решено переписать в пятой версии (как обычно — мотив для этого был).
Также стоит вспомнить главу «Эффект второй системы» из книги «Мифический человеко-месяц» (с ее публикации в 1975 году ничего не изменилось):