Он вообще ничего не понимает в базах. От слова совсем. Даже не знает, что такое JOIN.
хм, ну и что? С руководителем проекте можно говорить о требованиях и о том как система должна работать в понятных ему категориях. Не нужно понимать как работает джойн, чтобы понимать что данные не должны дублироваться иначе будут проблемы.
Программисту дали тренингов и попросили ходить в книжный клуб? Если в рабочее время то ходишь с ноутом и занимаешься своими делами. Если в нерабочее не ходишь.
Все эти штуки вообще вызывают ощущение что компании и продукт то не очень был нужен, если ключевого сотрудника отрывают от работы ради непонятно чего. На ближайшей планерке спросят когда фича будет готова, он говорит что у него нет свободного времени потому что оно все в тренингах и потому что соседи отвлекают и сразу волшебным образом и от тренингов освободят и в тихий угол пересадят. Ну это при условии что фичи эти реально нужны.
Это я если че не в обиду программисту, просто поясняю что даже при этих условиях вероятно можно было бы спокойно найти способ работать и дальше если бы он не держал все в себе а просто честно рассказывал что именно его беспокоит. Ну знаете 1-on-1, ретроспективы они в этом плане существо помогают.
Поэтому первым делом снимаю подлокотники, руки лежат на столе получается удобно и без выреза. Хотя с вырезом конечно удобнее, но уж очень специфичный стол выходит. И хорошо становится только в угол комнаты.
Я бы например спросил почему программа выводит каждый раз результаты в случайном порядке ( потому что го рандомизирует вывод мэпов, чтобы программисты не ленились явно сортировать ), ну и там поговорить о возможных проблемах
Ситуация знакомая. Когда создаешь проект которым пользуются люди, обязательно найдутся те что буду обвинять создателей во всех смертных грехах, угрожать, оскорблять.
Одно дело когда ты часть большого проекта, тогда тебя прикрывают другие люди, да и ответственность более размазана. А если ты на проекте сам ну или вас человек пять то каждому достается по полной программе от подобных неадекватов.
Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция searchCompany() на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.
При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
Разница лишь в том, что нейросети и ИИ имеют двоичный код, а ДНК человека состоит из четырех нуклеотидов, а это значит, что в ДНК можно закодировать на порядок больше информации.
Мда.
Вот и уровень статьи.
Но вообще-то нет, можно закодировать одинаково бесконечное количество информации. Более того двоичный код, это лишь условность, способ хранения данных а не сами данные. Для примера можете распечтать программу (или данные нейронки ) в тексте в base64 на бумаге. Теперь о чудо у нас 62 разных символа, значит ли это что мы только что прошли через удивительный эволюционный скачок и теперь программа может содержать больше комбинаций чем оригинальная хранящаяся в битах ?
Да вы правы. Годы идут, поддерживать рабочую линукс систему если и стало проще, но не сказать чтобы намного.
И если раньше я всем родственникам ставил условную Xubuntu то теперь просто рекомендую купить андроид планшет или Chromebook если людям нужна клавиатура. Это полностью закрывает их потребности ( обычных пользователей которым интернет, мессенджеры, фильмы и тд ), и при этом не требует никакой поддержки. Андроид и ХромОС просто работают. Софт ставится из магазина, никаких страшных надписей, поддержка всего железа.
И если честно я не думаю что это плохо. Пока десктопный линукс нишевой продукт, пока он пролетает под радарами крупных игроков на нем можно нормально жить. Меньше малвари, меньше шпионского говна, меньше внимания.
А убогое и глючное ГУИ, ну что делать, за мои 15+ лет с линуксом уже привык и получаю удовольствие. Стокгольмский синдром видимо.
Ну так любой нужный кому-то инструмент делается во множестве вариантов. У всех свои сценарии использования, все фокусируются на своих сильных сторонах.
Ну и учитывайте что курл это огромная куча сетевых протоколов, тогда как почти всем нужно только http/https
хм, ну и что? С руководителем проекте можно говорить о требованиях и о том как система должна работать в понятных ему категориях. Не нужно понимать как работает джойн, чтобы понимать что данные не должны дублироваться иначе будут проблемы.
Программисту дали тренингов и попросили ходить в книжный клуб? Если в рабочее время то ходишь с ноутом и занимаешься своими делами. Если в нерабочее не ходишь.
Все эти штуки вообще вызывают ощущение что компании и продукт то не очень был нужен, если ключевого сотрудника отрывают от работы ради непонятно чего. На ближайшей планерке спросят когда фича будет готова, он говорит что у него нет свободного времени потому что оно все в тренингах и потому что соседи отвлекают и сразу волшебным образом и от тренингов освободят и в тихий угол пересадят. Ну это при условии что фичи эти реально нужны.
Это я если че не в обиду программисту, просто поясняю что даже при этих условиях вероятно можно было бы спокойно найти способ работать и дальше если бы он не держал все в себе а просто честно рассказывал что именно его беспокоит. Ну знаете 1-on-1, ретроспективы они в этом плане существо помогают.
Поэтому первым делом снимаю подлокотники, руки лежат на столе получается удобно и без выреза. Хотя с вырезом конечно удобнее, но уж очень специфичный стол выходит. И хорошо становится только в угол комнаты.
Не спорю, я лишь отвечал на конкретный коммент о том можно ли сделать функцию лучше при сохранении функциональности. Считаю что да, можно и намного.
Конечно,
time.Format()
вполне стандартная функция, ей часто пользуются.Ну допустим так
https://play.golang.com/p/bSqTHq9obhJ
Я бы например спросил почему программа выводит каждый раз результаты в случайном порядке ( потому что го рандомизирует вывод мэпов, чтобы программисты не ленились явно сортировать ), ну и там поговорить о возможных проблемах
Ситуация знакомая. Когда создаешь проект которым пользуются люди, обязательно найдутся те что буду обвинять создателей во всех смертных грехах, угрожать, оскорблять.
Одно дело когда ты часть большого проекта, тогда тебя прикрывают другие люди, да и ответственность более размазана. А если ты на проекте сам ну или вас человек пять то каждому достается по полной программе от подобных неадекватов.
"дистопией" по-русски мы обычно говорим Антиутопия.
Для тех кто как и я полез гуглить это выглядит так
Lego Millennium Falcon
Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Мой любимый пример выглядит так:
Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция
searchCompany()
на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
Как будто человеку не придется убедится что они что-то в принципе тестируют.
Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
Звучит очень опасно, через пару лет уже появится свой красный степлер.
А может быть даже с отрицательным потреблением!
Зачем мне ноутбук если у меня будет специально обученный человек? Я просто скажу человеку сделать то что сейчас делаю руками на ноуте =)
Ну вот я таскаю ноут с собой каждый день, и хочу сказать что отлично чувствую разницу между 1кг и 1.5кг. Из семилетнего возраста уже давно вышел.
Еще учтите что в рюкзаке кроме ноута могут быть другие вещи, и в какой-то момент каждые лишние полкило ощущаются совсем иначе.
Мда.
Вот и уровень статьи.
Но вообще-то нет, можно закодировать одинаково бесконечное количество информации. Более того двоичный код, это лишь условность, способ хранения данных а не сами данные. Для примера можете распечтать программу (или данные нейронки ) в тексте в base64 на бумаге. Теперь о чудо у нас 62 разных символа, значит ли это что мы только что прошли через удивительный эволюционный скачок и теперь программа может содержать больше комбинаций чем оригинальная хранящаяся в битах ?
Да вы правы. Годы идут, поддерживать рабочую линукс систему если и стало проще, но не сказать чтобы намного.
И если раньше я всем родственникам ставил условную Xubuntu то теперь просто рекомендую купить андроид планшет или Chromebook если людям нужна клавиатура. Это полностью закрывает их потребности ( обычных пользователей которым интернет, мессенджеры, фильмы и тд ), и при этом не требует никакой поддержки. Андроид и ХромОС просто работают. Софт ставится из магазина, никаких страшных надписей, поддержка всего железа.
И если честно я не думаю что это плохо. Пока десктопный линукс нишевой продукт, пока он пролетает под радарами крупных игроков на нем можно нормально жить. Меньше малвари, меньше шпионского говна, меньше внимания.
А убогое и глючное ГУИ, ну что делать, за мои 15+ лет с линуксом уже привык и получаю удовольствие. Стокгольмский синдром видимо.
Автор а теперь пожалуйста тоже самое про Книги/Фильмы/Шахматы
Ну так любой нужный кому-то инструмент делается во множестве вариантов. У всех свои сценарии использования, все фокусируются на своих сильных сторонах.
Ну и учитывайте что курл это огромная куча сетевых протоколов, тогда как почти всем нужно только http/https