И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
А достаточно хорошим, сильным и готовым он конечно же должен родиться, не иначе
Люди же не едят деньги, не живут в домах из денег, не отапливают жилье деньгами, не заправляют автомобиль деньгами. Люди даже не копят деньги в деньгах, потому что деньги сильно дешевеют. Деньги нужны только для того чтобы в краткосрочной перспективе обменять их на еду, жилье, топливо и услуги. Допустим, есть заправка на которой в автомобили заливают полный бак бензина без оплаты. Ну и вот, зачем тут деньги. Топливо перепродать нельзя, поэтому нет смысла его накапливать. Больше чем нужно чтобы доехать до пункта назначения вы все равно не потратите
Именно "почему"? Вот что-то сомневаюсь. Если программист создавший пулл реквест не удосужился описать суть изменений в описании пулл реквеста, на code review надо так и написать в комментарии, мол напиши суть. Без этого даже начинать code review нет смысла. Конечно, то что ИИ подсказывает об ошшибках, допущеных программистом, это крутая и полезная функция. Но это ведь и ранее было, всякие статические анализаторы кода работают и проверяют код уже давно
N100 все-таки уже намного дороже, чем Pi-шки. Pi-шки именно в качестве роутера как будто бы получше, они меньше и запитывать их можно от самого комтьютера или батарейки. N100 уже все-таки больше полноценный компьютер
Роботакси не будет дешевле для пассажиров, оно будет больше зарабатывать владельцам. Именно для этого его и делают. Роботакси ведь уже ездят в некоторых местах в США и Китае, стоимость поездки на нем выше
Безработица будет, но не потому что ИИ, а потому что в очередной раз кризис перепроизводства. В 30-е годы прошлого века не было никакого ИИ, а безработица была, и голод был
Это все Java головного мозга. Java программисты вынуждены изобретать подобные "классы" потому что у них нельзя передать функцию как параметр. В Go можно передать функцию как параметр, поэтому в Pipeline должны быть функции validate, calculate, generate. И не надо изобретать лишних ненужных типов
Очевидно нет, не шучу, ни одного смайлика не поставил :-)
А чтобы mandatory не было null надо просто сделать его примитивным типом boolean. А если оно не указано (в конфигурации или в запросе) то присваивать ему значение по-умолчанию. Которое всегда есть, но оно либо зашито глубоко в BooleanUtils либо сразу и очевидно присваивается из конфигурации
Проблема начинается в том, что есть целые языки, которые изначально подталкивают к ООП благодаря своему дизайну
Проблема начинается когд на ООП языках, в которых должны быть объекты (Java), программисты пишут по-старому в стиле С (на Spring c DTO где ...Controller и ...Service которые по сути просто свалка процедур, обрабатывают структуры DTO). Потому что не хотят переучиваться на новое
Язык используется не так как задумано, вот поэтому и получается плохо. Надо немножечко разобраться как в объектах-то писать
но вместо того чтобы прям так и написать в программе, был придуман какой-то очень сложный способ, какой-то совершенно ненужный -utils. Ненужное усложнение совершенно простых вещей - в этом проблема
Причем тут 5 собесов. Можно хоть сколько собесов пройти и алгоритмов знать, но если нет электричества, значит нет электричества. Это из разряда шутки про то сколько пррграммистов нужно, чтобы вкрутить лампочку
Для сохранения психического благополучия подросткам лучше поменьше смотреть YouTube
А достаточно хорошим, сильным и готовым он конечно же должен родиться, не иначе
Люди же не едят деньги, не живут в домах из денег, не отапливают жилье деньгами, не заправляют автомобиль деньгами. Люди даже не копят деньги в деньгах, потому что деньги сильно дешевеют.
Деньги нужны только для того чтобы в краткосрочной перспективе обменять их на еду, жилье, топливо и услуги.
Допустим, есть заправка на которой в автомобили заливают полный бак бензина без оплаты. Ну и вот, зачем тут деньги. Топливо перепродать нельзя, поэтому нет смысла его накапливать. Больше чем нужно чтобы доехать до пункта назначения вы все равно не потратите
Google на Pixel тоже выпускает прошивки. С вылизанностью конечно беда
Полтора года уже готовит, все никак не приготовит
Не вывозит Devin работу, не вывозит, приходится кожаным вкалывать по 80 часов в неделю
Именно "почему"? Вот что-то сомневаюсь.
Если программист создавший пулл реквест не удосужился описать суть изменений в описании пулл реквеста, на code review надо так и написать в комментарии, мол напиши суть. Без этого даже начинать code review нет смысла.
Конечно, то что ИИ подсказывает об ошшибках, допущеных программистом, это крутая и полезная функция. Но это ведь и ранее было, всякие статические анализаторы кода работают и проверяют код уже давно
На pi-шки устанавливается точно такая же полноценная серверная ось - debian.
Для роутера нужно-то, базовый сетевой функционал и vpn софт.
N100 все-таки уже намного дороже, чем Pi-шки. Pi-шки именно в качестве роутера как будто бы получше, они меньше и запитывать их можно от самого комтьютера или батарейки. N100 уже все-таки больше полноценный компьютер
Роботакси не будет дешевле для пассажиров, оно будет больше зарабатывать владельцам. Именно для этого его и делают. Роботакси ведь уже ездят в некоторых местах в США и Китае, стоимость поездки на нем выше
Глава компании продающей ИИ везде пихает свой ИИ.
Безработица будет, но не потому что ИИ, а потому что в очередной раз кризис перепроизводства. В 30-е годы прошлого века не было никакого ИИ, а безработица была, и голод был
интерфейс будет называться Validator, я про него и говорю, в Go он совершенно ненужен
Это все Java головного мозга. Java программисты вынуждены изобретать подобные "классы" потому что у них нельзя передать функцию как параметр.
В Go можно передать функцию как параметр, поэтому в Pipeline должны быть функции validate, calculate, generate. И не надо изобретать лишних ненужных типов
Еще бы объемчик вернули. Чтобы сразу было видно куда надо нажимать, а где просто текст. Сейчас приходится методом тыка определять, слишком плоско
Очевидно нет, не шучу, ни одного смайлика не поставил :-)
А чтобы mandatory не было null надо просто сделать его примитивным типом boolean. А если оно не указано (в конфигурации или в запросе) то присваивать ему значение по-умолчанию. Которое всегда есть, но оно либо зашито глубоко в BooleanUtils либо сразу и очевидно присваивается из конфигурации
Проблема начинается когд на ООП языках, в которых должны быть объекты (Java), программисты пишут по-старому в стиле С (на Spring c DTO где ...Controller и ...Service которые по сути просто свалка процедур, обрабатывают структуры DTO). Потому что не хотят переучиваться на новое
Язык используется не так как задумано, вот поэтому и получается плохо. Надо немножечко разобраться как в объектах-то писать
Проблема в том, что в этом коде имелось в виду
но вместо того чтобы прям так и написать в программе, был придуман какой-то очень сложный способ, какой-то совершенно ненужный -utils. Ненужное усложнение совершенно простых вещей - в этом проблема
Я недавно видел у нас проекте лютый треш
вот где ужас
Тоесть планируют бороться с мошенниками путем блокировки счетов жертв мошенников, и сажанием их в тюрьму.
Причем тут 5 собесов. Можно хоть сколько собесов пройти и алгоритмов знать, но если нет электричества, значит нет электричества. Это из разряда шутки про то сколько пррграммистов нужно, чтобы вкрутить лампочку