Война, очевидно, будет еще не один месяц. Нужно новое оружие, нужны деньги на другие потребности. И чем меньше будет поступать сейчас денег в РФ, тем быстрее эти деньги кончатся, и в том числе холодильник начнет побеждать пропаганду из зомбоящика.
Именно это сейчас и происходит. США рассматривают вариант отказа от российской нефти. Европа говорит прямо, что прямо сейчас не могут полностью отказаться, но ищут пути. Так что и от этого откажутся.
А блокировки, направленные на простых людей - это тоже правильно, если эти простые люди живут в простой стране, которая просто бомбит другую страну. Эти простые люди поддерживают власть (прямо или молчаливо), которая бомбит мирные города. Самый простой способ протеста - выехать, если не хотите протестовать. Это война, в Украине действительно каждый день умирают сотни простых людей (не военных), и наверное простые люди страны-агрессора должны ощутить определенные неудобства, не так ли?
Если есть белорусы, то самое время задуматься что делать прямо сейчас, во время референдума. У вас ещё есть шанс не запятнать себя так явно кровью, как РФ
Появится у вас проект на сотню-другую тысяч строк кода. Потом ещё пять. Это надо связать, появится какая-то Кафка. И вот внезапно вы уже забываете, что там вы вначале писали.
Адекватная ООП архитектура поможет вам разобраться как оно организовано. Статический контроль типов а) не даст поломать существующий код б) IDE поможет вам сориентироваться что и куда приходит в ваши методы.
В общем, прелести ООП и статической типизации проявляются на больших проектах. Для условного лендинга конечно хватит jquery и bootstrap.
Так не высмеивают, коммент к фотке нормальный, не злобный.
А так я считаю молодцы за последние посты. Чем-то по стилю начинают напоминать @Milfgard и читать реально интересно. Если при этом уберут переводные посты с трешовыми рекламными вставками в посте - круто, и я за такой контент на Хабре.
Смысл одной фразой - оцените ваш проект, если он подходит под скрам, то используйте его, а если нет - то не нужно, потому что скрам вам не подойдёт.
Как понять, что проект подходит под скрам непонятно, где грань между комплексным и простым - тоже.
Я считаю, что нужно учить инженерию требований, системное мышление, операционный менеджмент и это даст свои плоды. Скрам же есть смысл учить после всего этого, потому что это лишь верхушка айсберга, которую люди воспринимают как волшебную таблетку - применили скрам, и все порешалось.
Читать книги, в том числе и художественные. Я лично люблю НФ и фентези, и скажу за них. Каждая книга - построение в голове системы (персонажи, декорации, действия). Здесь поневоле придется включать голову и сосредотачиваться больше пяти минут, иначе книгу не поймёшь.
Вдруг окажется, что нам нужно авторизоваться в системе, и значит хранить-выдавать токены. Потом нам нужно хранить кучу информации о каждом юзер в БД. Потом строить связи между данными в БД. И мы оказываемся в ситуации, когда мы имеем базу данных и плоский набор функций для работы с этой БД. При этом нормальной локальной отладки не имеем, код локально без интернета глянуть не можем, перейти к другому провайдеру не можем — ведь мы завязаны на конкретного провайдера.
Аргумент, что можем пускать к разработке неопытных программистов звучит странно. К некритичным частям при разработке софта мы и так их пускаем, к критичным тоже пускаем, но делаем более строгий код-ревью. Что так, что так нужно проверять их код, а не надеяться, что серверлесс платформа вас защитит от дурака.
Дурак напишет вам серверлесс функцию, которая удалит вашу серверлесс базу данных. И бекапа у вас не будет, ведь все серверлесс)
Есть крутая книга на эту тему, "Мифический человекомесяц", и глава оттуда "Серебряной пули нет". Вкратце, не видно технических средств (языков, компиляторов) и т.д., которые смогут глобально ускорить разработку.
Потому что проблема не в том, чтобы записать алгоритм, а в том, чтобы его придумать. Задача же языка программирования — не мешать. Как здесь поможет серверлесс — мне непонятно. Как будет мешать — вполне понятно. Например, отсутствие нормальной IDE, которая будет показывать связи между различными частями кода уже будет тормозить вас.
Из интересных моментов, которые я сталкивался — это работа с каскадным удалением связанных сущностей.
Например, по дефолту hibernate при удалении связанных сущностей вначалей делает update связанной сущности, присваивая внешнему ключу значение null, а лишь потом удаляет связанную сущность. Фиксится поведение указанием updatable=false в аннотации @JoinColumn.
Ещё один момент — если мы указываем каскадное удаление связанных сущностей, то мы отдаем это на откуп hibernate, в БД ограничения указываются без on delete cascade. Как результат, мы не можем удалить главную сущность, не удалив всех родителей. Не всегда это нужно, и часто удобней чтобы БД контролировала ссылочную целостностность. Лечится это поведение прописыванием явным constraints в аннотации @ForeignKey.
В чем особенность передачи именно картинки? Любой файл прекрасно передается, ведь его можно представить в виде байтового потока, и запихнуть в сокет.
За шифрование — здесь явно смешение абстракций. Отдельный код должен шифровать-дешифровать. И совершенно другой — отправлять. Тогда можно будет использовать разные алгоритмы шифрования, и передавать эти же зашифрованные файлы не только сокетами.
Ну и субъективно — в вашей статье я не вижу уважения к читателю. Вы небрежно формулируете задачу, небрежно описываете решение, и статья тяжелее читается. Ну и судя по вашим ответам на комментарии вы плохо воспринимаете конструктивную критику. Если хотите расти как программист, вам нужно фиксить эти качества.
Автор не учитывает, что из рассмотренных языков лишь у джавы статическая типизация. Поэтому что-то большое в разы проще на ней писать. Компилятор кучу ошибок отловит ещё до запуска.
В node.js про ошибку же мы узнаем лишь после запуска, точнее как до соответствующего места кода дойдет исполнение. В худшем случае код исполнится без ошибок, но неправильно (например, передали функции меньше параметров чем нужно).
Поэтому статическая типизация в языке, который юзается в фреймворкк — то, на что я бы приоритетно обращал внимание. С ростом проекта хайповость и смузиевость технологии будет меркнуть на фоне его поддержки и развития.
Это не значит, что Java — плохой язык. Но он не создан для решения тех задач, для решения которых отлично подходит функциональное программирование. Например — для управления базами данных или для разработки приложений из сферы машинного обучения.
Эм, джава, которая в куче энтерпрайз софта, и которая отлично работает с базами данных, оказывается не для этого создана?
Как мне кажется, для работы с базами данных джава отлично подходит. По логике в статье метод, в котором вставляются данные в БД (insert) уже не будет чистым — ведь он ничего не возвращает. Но в реальной жизни у нас есть изменяемое состояние (та же БД), и пример выше кажется надуманным.
"Наш мозг развивался в сторону «делания чего-то», а не в сторону выстраивания сложной иерархии из абстрактных объектов"
Эм, так человек же социальное животное, и для выживания строил сложные социальные схемы в голове, когда ещё обезьяной был. Тот вожак, того не тронь, того почеши, с тем за ягодами сходить можно завтра.
То есть, как раз на обработку достаточно большого количества объектов и связей мозг заточен. Есть число Данбара, согласно с которым 150-200 обьектов и связей между ними человек в голове удерживает.
Почитал комментарии, и понимаю что да, костыльное решение получилось. Могу сказать, что поскольку никто не знал как правильно — делали как умеем.
Я так понимаю, что у вас была такая же ситуация (проходили похожий путь).
К чему вы все же пришли, к какому стеку?
Я склоняюсь пока к варианту поднять Jenkins, и делать что-то вроде:
1) Jenkins из jenkinsfile собирает на той же машине, где запущен jenkins билд — это jar файл.
2) Дальше jar файл копируется на целевую машину
3) Каким-то скриптом убиваем старый процесс, запускаем новый.
Пока до конца не понимаю, зачем использовать ansible, например, если процесс билда — это mvn package.
Понимаю, о чем вы. Стоял выбор между совсем не автоматизировать, и автоматизировать хоть как-то — никто не умел делать это правильно. Выбрали такой вариант.
Ну и можно не поддерживать. То есть, в крайнем случаем откатиться нужно до ручной сборки, заходя по SSH на сервер, но больше ничего не поломается.
Я хорошо знаю Java, и очень базово — bash. Выбрал инструмент, на котором смог сделать решение. Согласен с вами, что исключительно bash + утилиты получше решение, по крайней мере с точки зрения потребляемых ресурсов.
Я также не понимаю возмущений и недовольства айтишников.
Очевидно же, что проводится специальная финансовая операция, цель которой - девалютизация российских программистов.
Война, очевидно, будет еще не один месяц. Нужно новое оружие, нужны деньги на другие потребности. И чем меньше будет поступать сейчас денег в РФ, тем быстрее эти деньги кончатся, и в том числе холодильник начнет побеждать пропаганду из зомбоящика.
Именно это сейчас и происходит. США рассматривают вариант отказа от российской нефти. Европа говорит прямо, что прямо сейчас не могут полностью отказаться, но ищут пути. Так что и от этого откажутся.
А блокировки, направленные на простых людей - это тоже правильно, если эти простые люди живут в простой стране, которая просто бомбит другую страну. Эти простые люди поддерживают власть (прямо или молчаливо), которая бомбит мирные города. Самый простой способ протеста - выехать, если не хотите протестовать. Это война, в Украине действительно каждый день умирают сотни простых людей (не военных), и наверное простые люди страны-агрессора должны ощутить определенные неудобства, не так ли?
Вы такой треш написали, я попытался вчитываться, но это жесть. И эти стоковые картинки, добавляющие пластмассовости статьи.
В общем, low cost копирайт
Если есть белорусы, то самое время задуматься что делать прямо сейчас, во время референдума. У вас ещё есть шанс не запятнать себя так явно кровью, как РФ
Хех, фронтендер детектед)
Появится у вас проект на сотню-другую тысяч строк кода. Потом ещё пять. Это надо связать, появится какая-то Кафка. И вот внезапно вы уже забываете, что там вы вначале писали.
Адекватная ООП архитектура поможет вам разобраться как оно организовано. Статический контроль типов а) не даст поломать существующий код б) IDE поможет вам сориентироваться что и куда приходит в ваши методы.
В общем, прелести ООП и статической типизации проявляются на больших проектах. Для условного лендинга конечно хватит jquery и bootstrap.
Поставил статье минус за кликбейт.
1) 5.7 миллиарда - это оценка компании, а не рынка. Компании оцениваются по другим принципам.
2) Компания продает не только айфоны, а и устройства других производителей.
Такая статья улетела бы в минуса даже на Пикабу, зачем ее выкладывать на хабр, где большинство людей таки умеет анализировать информацию - не понимаю.
Глубина все ближе)
Скоро появятся виртуальные офисы, и вопрос "У вас есть офис?" заиграет новыми красками.
Так не высмеивают, коммент к фотке нормальный, не злобный.
А так я считаю молодцы за последние посты. Чем-то по стилю начинают напоминать @Milfgard и читать реально интересно. Если при этом уберут переводные посты с трешовыми рекламными вставками в посте - круто, и я за такой контент на Хабре.
Смысл одной фразой - оцените ваш проект, если он подходит под скрам, то используйте его, а если нет - то не нужно, потому что скрам вам не подойдёт.
Как понять, что проект подходит под скрам непонятно, где грань между комплексным и простым - тоже.
Я считаю, что нужно учить инженерию требований, системное мышление, операционный менеджмент и это даст свои плоды. Скрам же есть смысл учить после всего этого, потому что это лишь верхушка айсберга, которую люди воспринимают как волшебную таблетку - применили скрам, и все порешалось.
Читать книги, в том числе и художественные. Я лично люблю НФ и фентези, и скажу за них. Каждая книга - построение в голове системы (персонажи, декорации, действия). Здесь поневоле придется включать голову и сосредотачиваться больше пяти минут, иначе книгу не поймёшь.
Закон дырявых абстракций никто не отменял.
Вдруг окажется, что нам нужно авторизоваться в системе, и значит хранить-выдавать токены. Потом нам нужно хранить кучу информации о каждом юзер в БД. Потом строить связи между данными в БД. И мы оказываемся в ситуации, когда мы имеем базу данных и плоский набор функций для работы с этой БД. При этом нормальной локальной отладки не имеем, код локально без интернета глянуть не можем, перейти к другому провайдеру не можем — ведь мы завязаны на конкретного провайдера.
Аргумент, что можем пускать к разработке неопытных программистов звучит странно. К некритичным частям при разработке софта мы и так их пускаем, к критичным тоже пускаем, но делаем более строгий код-ревью. Что так, что так нужно проверять их код, а не надеяться, что серверлесс платформа вас защитит от дурака.
Дурак напишет вам серверлесс функцию, которая удалит вашу серверлесс базу данных. И бекапа у вас не будет, ведь все серверлесс)
Есть крутая книга на эту тему, "Мифический человекомесяц", и глава оттуда "Серебряной пули нет". Вкратце, не видно технических средств (языков, компиляторов) и т.д., которые смогут глобально ускорить разработку.
Потому что проблема не в том, чтобы записать алгоритм, а в том, чтобы его придумать. Задача же языка программирования — не мешать. Как здесь поможет серверлесс — мне непонятно. Как будет мешать — вполне понятно. Например, отсутствие нормальной IDE, которая будет показывать связи между различными частями кода уже будет тормозить вас.
Из интересных моментов, которые я сталкивался — это работа с каскадным удалением связанных сущностей.
Например, по дефолту hibernate при удалении связанных сущностей вначалей делает update связанной сущности, присваивая внешнему ключу значение null, а лишь потом удаляет связанную сущность. Фиксится поведение указанием updatable=false в аннотации @JoinColumn.
Ещё один момент — если мы указываем каскадное удаление связанных сущностей, то мы отдаем это на откуп hibernate, в БД ограничения указываются без on delete cascade. Как результат, мы не можем удалить главную сущность, не удалив всех родителей. Не всегда это нужно, и часто удобней чтобы БД контролировала ссылочную целостностность. Лечится это поведение прописыванием явным constraints в аннотации @ForeignKey.
В чем особенность передачи именно картинки? Любой файл прекрасно передается, ведь его можно представить в виде байтового потока, и запихнуть в сокет.
За шифрование — здесь явно смешение абстракций. Отдельный код должен шифровать-дешифровать. И совершенно другой — отправлять. Тогда можно будет использовать разные алгоритмы шифрования, и передавать эти же зашифрованные файлы не только сокетами.
Ну и субъективно — в вашей статье я не вижу уважения к читателю. Вы небрежно формулируете задачу, небрежно описываете решение, и статья тяжелее читается. Ну и судя по вашим ответам на комментарии вы плохо воспринимаете конструктивную критику. Если хотите расти как программист, вам нужно фиксить эти качества.
Автор не учитывает, что из рассмотренных языков лишь у джавы статическая типизация. Поэтому что-то большое в разы проще на ней писать. Компилятор кучу ошибок отловит ещё до запуска.
В node.js про ошибку же мы узнаем лишь после запуска, точнее как до соответствующего места кода дойдет исполнение. В худшем случае код исполнится без ошибок, но неправильно (например, передали функции меньше параметров чем нужно).
Поэтому статическая типизация в языке, который юзается в фреймворкк — то, на что я бы приоритетно обращал внимание. С ростом проекта хайповость и смузиевость технологии будет меркнуть на фоне его поддержки и развития.
Эм, джава, которая в куче энтерпрайз софта, и которая отлично работает с базами данных, оказывается не для этого создана?
Как мне кажется, для работы с базами данных джава отлично подходит. По логике в статье метод, в котором вставляются данные в БД (insert) уже не будет чистым — ведь он ничего не возвращает. Но в реальной жизни у нас есть изменяемое состояние (та же БД), и пример выше кажется надуманным.
"Наш мозг развивался в сторону «делания чего-то», а не в сторону выстраивания сложной иерархии из абстрактных объектов"
Эм, так человек же социальное животное, и для выживания строил сложные социальные схемы в голове, когда ещё обезьяной был. Тот вожак, того не тронь, того почеши, с тем за ягодами сходить можно завтра.
То есть, как раз на обработку достаточно большого количества объектов и связей мозг заточен. Есть число Данбара, согласно с которым 150-200 обьектов и связей между ними человек в голове удерживает.
Почитал комментарии, и понимаю что да, костыльное решение получилось. Могу сказать, что поскольку никто не знал как правильно — делали как умеем.
Я так понимаю, что у вас была такая же ситуация (проходили похожий путь).
К чему вы все же пришли, к какому стеку?
Я склоняюсь пока к варианту поднять Jenkins, и делать что-то вроде:
1) Jenkins из jenkinsfile собирает на той же машине, где запущен jenkins билд — это jar файл.
2) Дальше jar файл копируется на целевую машину
3) Каким-то скриптом убиваем старый процесс, запускаем новый.
Пока до конца не понимаю, зачем использовать ansible, например, если процесс билда — это mvn package.
Понимаю, о чем вы. Стоял выбор между совсем не автоматизировать, и автоматизировать хоть как-то — никто не умел делать это правильно. Выбрали такой вариант.
Ну и можно не поддерживать. То есть, в крайнем случаем откатиться нужно до ручной сборки, заходя по SSH на сервер, но больше ничего не поломается.
Я хорошо знаю Java, и очень базово — bash. Выбрал инструмент, на котором смог сделать решение. Согласен с вами, что исключительно bash + утилиты получше решение, по крайней мере с точки зрения потребляемых ресурсов.