Подпишусь под каждой строчкой статьи. Спасибо! Часто и даже очень часто, и более того, все чаще и чаще, встречаешься с ситуацией "кровавого энтерпрайз", где требования сверхнадежности просто убивают продукт, например: "146% работоспособность в ущерб времени отклика web-сайта до 10-30секунд".. Повальное применение сторонних решений, доходящее до HR-требования, типа "программист-разработчик не должен смотреть в код стороннего пакета, но должен уметь применять их легко и быстро" .. видел и такое уже.
.. PSR рекомендации, stateless реализации .. всё это было бы очень смешно, если бы не было так грустно порой.
Сам, "старый велосипедист" с 1979года в ИТ, со вьевшимся в пальцы пониманием термина "стоимость команды процессора". Совершенно не нужное и вредное свойство для любого HR.
Развел в kicad 3 платы: 2 контроллера Atmel Mega2560, последнюю (rev2) 56х800мм со всеми выводами под сдвоенные разьемы и к ней, того же формата плату расширения ОЗУ с 8кб до 520кб. Сделал герберы, как описано в инструкции и отдал китайцам. За 10 баксов получил 10 комплектов, собрал 4шт - всё работало штатно.
Спасибо за статью, прочел. Оказалось "сделал всё по правилам" .. а так бы и не узнал. ;)
Это было достаточно давно, ещё до появления TLS и прочих SSL протоколов.. ;) Да, применялось как защита от Man in middle, но и ещё попутно позволяло человеку иметь достаточно простой пароль, который не передавался в "открытом виде".
В свое время предлагал кмк, простое решение по простым паролям:
Форма логирования отдавалась в браузер с неким "правилом", по которому пользователь должен был изменить свой пароль. Затем на сервере применялась вторая часть правила для получения правильного пароля.
На практике столкнулся с плохой читаемостью синтаксиса дженериков. [] явно не лучший выбор, но возможно это было связано с количеством параметров >2 и длинным неймингом по типу С#. Очень тяжело было читать чужой код. Кмк <> было бы нагляднее.
Очень хочется посмотреть на того сеньора, который это напишет в вацап с Генеральным Директором градообразующей фирмы, который считает что раз он математик по образованию, то способен поставить вам ТЗ "на пальцах" прямо вот тут, в вацапе и только ваша непроходимая тупость не позволяет ему донести до вас такие простые вещи. ;)
В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
Поддержу. ДРАКОН как раз позволяет визуализировать ТЗ и часто определить "Царскую дорогу", одновременно снижая цикломатическую сложность решения разработчика.
Странное и повсеместное утверждение что синтаксис Go подобен С/С++ .. скорее уже Пасклю, Модуле, Джаве. Даже := взято оттуда! Кстати, если он Си-подобен, то где мои любимые union? :) (дженерики не предлагать). Горутины и каналы .. похоже, что Роберт Пайк притащил в язык Хоаровское взаимодействие процессов, забыв что оно впервые реализовано в Ада.. :) Что не нравится в Go:
err != nil -- это да, "вне конкуренции". Кстати, группы разработчиков часто настраивают линтеры так, чтобы не обработанную ошибку нельзя было подавить через _!
запятая в конце строк.. хотели избавиться от ;, зато наплодили запятых. Ни одна закрывающаяся скобка толко на новую строку не переносится.
for _,item := range slice(map|array) {} 80% циклов с таким перебором .. именно так, скрипач не нужен!
[]interface{} -- зубная боль гошника, не смотря на то, что стандартная библиотека этим переполнена по самое не балуйся.
Медленный runtime, использование пакета reflect в недрах стандартной библиотеки, что ещё снижает производительность.
Отсутствие select над слайсом каналов. В Аде такое есть, однако..
Тотальная передача по значению. Дорого и содержит острые подводные камни.
Что нравится в Go:
Простота и лаконичность синтаксиса. Это вам не Ада.. :)
Небольшая стандартная библиотека, закрывающая (пусть и не эффективно) большую часть потребностей. В принципе есть всё, что требуется.
Интерфейсы, отделенные от структур (объектов). Очень интересный и оригинальный подход в обход ООП. Та же "таблица виртуальных методов", но .. отделенная от класса. Очень переспективное направление, кмк.
ИМХО, как мнение к опросу, на который видимо опоздал.. не для споров. :)
Подпишусь под каждой строчкой статьи. Спасибо! Часто и даже очень часто, и более того, все чаще и чаще, встречаешься с ситуацией "кровавого энтерпрайз", где требования сверхнадежности просто убивают продукт, например: "146% работоспособность в ущерб времени отклика web-сайта до 10-30секунд".. Повальное применение сторонних решений, доходящее до HR-требования, типа "программист-разработчик не должен смотреть в код стороннего пакета, но должен уметь применять их легко и быстро" .. видел и такое уже.
.. PSR рекомендации, stateless реализации .. всё это было бы очень смешно, если бы не было так грустно порой.
Сам, "старый велосипедист" с 1979года в ИТ, со вьевшимся в пальцы пониманием термина "стоимость команды процессора". Совершенно не нужное и вредное свойство для любого HR.
Упс, ошибся. Размер платы 56х88мм, не 800 конечно же. Получилось примерно так: https://vk.com/id484853030?z=photo484853030_456239018%2Fphotos484853030
Развел в kicad 3 платы: 2 контроллера Atmel Mega2560, последнюю (rev2) 56х800мм со всеми выводами под сдвоенные разьемы и к ней, того же формата плату расширения ОЗУ с 8кб до 520кб. Сделал герберы, как описано в инструкции и отдал китайцам. За 10 баксов получил 10 комплектов, собрал 4шт - всё работало штатно.
Спасибо за статью, прочел. Оказалось "сделал всё по правилам" .. а так бы и не узнал. ;)
Это было достаточно давно, ещё до появления TLS и прочих SSL протоколов.. ;) Да, применялось как защита от Man in middle, но и ещё попутно позволяло человеку иметь достаточно простой пароль, который не передавался в "открытом виде".
В свое время предлагал кмк, простое решение по простым паролям:
Форма логирования отдавалась в браузер с неким "правилом", по которому пользователь должен был изменить свой пароль. Затем на сервере применялась вторая часть правила для получения правильного пароля.
На практике столкнулся с плохой читаемостью синтаксиса дженериков. [] явно не лучший выбор, но возможно это было связано с количеством параметров >2 и длинным неймингом по типу С#. Очень тяжело было читать чужой код. Кмк <> было бы нагляднее.
Коллега прямо сейчас сидит парсит БД с названиями таблиц "townНазвания" .. в формате EAV с такой же мешаниной анг-rus.
Очень хочется посмотреть на того сеньора, который это напишет в вацап с Генеральным Директором градообразующей фирмы, который считает что раз он математик по образованию, то способен поставить вам ТЗ "на пальцах" прямо вот тут, в вацапе и только ваша непроходимая тупость не позволяет ему донести до вас такие простые вещи. ;)
Хорошо было описано в работе (Баррон?) по истории создания ОС 360. Лучше не напишу.. извините. ;)
Да, запамятовал уже.. Ещё раньше было хранение версий в отдельных папках на компе... ;) Ещё раньше - шкаф с полками для колод перфокарт.
В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
Поддержу. ДРАКОН как раз позволяет визуализировать ТЗ и часто определить "Царскую дорогу", одновременно снижая цикломатическую сложность решения разработчика.
Вот тоже на этом споткнулся и не понял почему последнее решение стало решением.
Странное и повсеместное утверждение что синтаксис Go подобен С/С++ .. скорее уже Пасклю, Модуле, Джаве. Даже := взято оттуда! Кстати, если он Си-подобен, то где мои любимые union? :) (дженерики не предлагать). Горутины и каналы .. похоже, что Роберт Пайк притащил в язык Хоаровское взаимодействие процессов, забыв что оно впервые реализовано в Ада.. :) Что не нравится в Go:
err != nil -- это да, "вне конкуренции". Кстати, группы разработчиков часто настраивают линтеры так, чтобы не обработанную ошибку нельзя было подавить через _!
запятая в конце строк.. хотели избавиться от ;, зато наплодили запятых. Ни одна закрывающаяся скобка толко на новую строку не переносится.
for _,item := range slice(map|array) {} 80% циклов с таким перебором .. именно так, скрипач не нужен!
[]interface{} -- зубная боль гошника, не смотря на то, что стандартная библиотека этим переполнена по самое не балуйся.
Медленный runtime, использование пакета reflect в недрах стандартной библиотеки, что ещё снижает производительность.
Отсутствие select над слайсом каналов. В Аде такое есть, однако..
Тотальная передача по значению. Дорого и содержит острые подводные камни.
Что нравится в Go:
Простота и лаконичность синтаксиса. Это вам не Ада.. :)
Небольшая стандартная библиотека, закрывающая (пусть и не эффективно) большую часть потребностей. В принципе есть всё, что требуется.
Интерфейсы, отделенные от структур (объектов). Очень интересный и оригинальный подход в обход ООП. Та же "таблица виртуальных методов", но .. отделенная от класса. Очень переспективное направление, кмк.
ИМХО, как мнение к опросу, на который видимо опоздал.. не для споров. :)