Самый лучший способ разработки — линейный, без веток, потому как самый простой. Усложнения появляются лишь по мере необходимости, а не потому, что это круто и модно. Все заморочки вокруг кода не добавляют ценности продукту, и платить за них клиент не будет.
Ну, одно время было что-то подобное ввиде JQuery. Но сейчас в экосистеме JS любая stdlib просуществует не дольше месяца, пока очередной школьник ни накропает свою с блекджеком и пр...
Поэтому для реально работающих приложений — чатов и т.п. приходится допиливать некоторую логику по доставке пропущенных сообщений (сообщения могут теряться в процессе разрыва и восстановления соединения)
Да, и очень часто бизнес логика напрямую завязана на состояние коннекшна. Например показать юзеру его пинг, или показать в чате, что игрок реконнетится. На сервере для реконнектов нужно контролировать тайманты на сессию, а также уметь жестко дисконнектить клиента. А еще нужно уметь настраивать коннекшн на более низком уровне (tcp_nodelay, keep_alive, send/receive buffer, etc...), защищаться от разного рода атак на ресурсы, напр. контролировать количество коннектов на клиента, или организовывать delay-пулы против overload-а. Все это становится недоступно при использовании абстрактных надстроек более высокого уровня.
Всегда проще написать свой велосипед, понятный и заточенный под конкретную задачу, чем разбираться в абстрактном мультифункциональном протоколе, ломать голову как с помощью него реализовать необходимое, бороться с ограничениями в дизайне, а затем на проде ловить лютый гемор по поводу неучтенных нюансов в поведении провайдера и низлежащих протоколов.
Есть другая либа SockJS, которая эмулирует вебсокет с разными транспортами. В отличие от socket.io, заточена под разные бэкенды. Для джавистов есть Atmosphere Framework, который я пробовал юзать.
Тем не менее на реальном проде использование транспортных врапперов отнюдь не так хорошо, как кажется — вылезают такие кейсы, которые и не снились. Требуется спуск на уровень на транспортный уровень, который вы уже не контролируете, либо библиотека недостаточно гибкая, чтобы покрыть этот кейс. Особенно актуально на мобильной связи. Поэтому, начиная с какого-то момента, требуется разработка собственного протокола с использованием голого вебсокета или лонгполлинга.
Безусловно интересно, полезно и познавательно знать, как все устроено под капотом, и какие решения по оптимизации существуют. Но реальные кейсы, где это реально необходимо, очень специфичны и малочисленны. Одно время Шипилев своими докладами породил целый класс "борцов за перформанс", которые бенчили все, что ни попадя, и не давали закрыть тикет только потому, что у куска кода сложность не O(n), а O(n²), когда реально n не превышало 10. Я лично почти не встречал острой необходимости оптимизации java-кода — все перформансные накладки были либо в изначально плохой архитектуре решения, либо в базе данных.
Если вы уперлись в предел масштабирования, то в этих случаях и перформансная оптимизация сильно не поменяет погоды. Я имею ввиду все то, о чем балаболят на конференциях — покрутить такие-то настройки JVM, заменить один объект на другой, отрефакторить такой-то кусок, и тому подобное. Там уже требуются серьезные архитектурные изменения, которые затрагивают всю систему целиком. А вот рыхлить уже работающий и отлаженный бизнес-компонент там, где общая архитектура еще позволяет масштабировть, ради прибавки в 10-15% — всегда дешевле и проще просто докупить железа.
У меня на Mac возникла маленькая техническая проблема, на Stack Overflow нашёл совет «установить Xcode и принять её условия использования». Моя реакция: странно скачивать 8-гигабайтную IDE для нажатия одной кнопки, но если поможет, почему бы и нет.
Ровно таким же принципом руководствуется большинство девелоперов, который можно перефразировать как: "машина мощная — справится". Почему так: потому что единственной целью на сегодняшний день в разработке является эффективность: сделать максимум при минимуме затрат. Никто не заинтересован тратить время (и деньги) не только для оптимизации программы, но мало-мальски на изучение и овладение релевантными средствами разработки. Зачем? Запихнем все в браузер, запакуем сам браузер и дело в шляпе! Все накладки с производительностью будут решены в завтрашнем более мощном железе. Такие девелоперы забывают лишь одно — за ограниченные ресурсы железа борется одновременно сразу куча таких же пухлых приложений.
Общий вывод: громкие тезисы «раньше всё работало быстрее и лучше» оказываются очевидной неправдой.
А дело тут не в быстроте. В далеких 90-х Word и Excel запускались на 4M и даже позволяли выполнять работу. Сегодня мощности железа возросли в тысячи раз, потребности того же оффиса — в сотни, но самое главное — функционал — грубо говоря, лишь в разы.
Использование смартфона выглядело как постоянное ожидание: что бы ты ни хотел сделать, это включает периоды «стоишь и тупишь».
Дык и сейчас так, если у тебя телефону пару лет. Причем, одни и те же приложения когда-то не тупили на старом телефоне. Теперь и на нынешнем тупят. И так постоянно. Очено наглядный пример — GMail.
Недавно я проделал простой эксперимент: открыл программу нашей Java-конференции JPoint и посмотрел, в скольки описаниях докладов встретится что-то о производительности.
Потому что в Java уже больше не о чем говорить. Это либо новые фишки в JDK N+1, либо вездессущий Spring Boot, либо перформанс. Хотя там, где живет Java, любое перформансное просаживание легко решается докупкой железа.
Если вы упоролись по выравниванию данных, и ваше приложение стало чуть-чуть меньше и быстрее, но вы потратили на это неделю, которая могла бы уйти на полезную фичу, то вы сделали пользователю лучше или хуже?
Поэтому вместо чтобы разобраться с QT берем Электрон со встроенным браузером и херачим на джаваскрипте весь GUI и всю логику. Вместо того, чтобы критические части писать на C/C++ берем Python и вперед! Железо мощное — справится! А юзер миллионер — раскошелится!
Для меня и многих это тоже большой вопрос. Кроме того мое мнение, что отсутствие продуктов в супермаркетах вовсе не связано с перебоями в снабжении. Просто у всех сетей уже давно просчитана вся логистика на основании статистики потребления и на этой основе заключены контракты с поставщиками и внутренние процессы производства. Поэтому система не приспособлена даже к небольшим, но резким перепадам в спросе.
Привет из Мадрида! Тоже всей семьей заперты на "удаленке" — благо наши компании ее уже давно практикуют, и вся инфраструктура налажена. Детям раздают задания по вебу и ватсапу, задания они отправляют на электронную почту школы. На улицах полиция контролирует передвижения, за неподчинение требованиям — штраф €1500. Все закрыто. В меркадону на входе очередь, квоты на продукты, полки полупустые… Самые ходовые продукты — мясо, молоко, макароны, бобовые, овощи и сортирная бумага.
Верно ли то же самое, если все апдейты делаются в одной транзакции? То есть реально новая запись делается при каждом апдейте, или же делается одна финальная запись при commit-е?
По большей части мнение автора, основанное в лучшем случае на субъективном опыте, а скорей всего — исключительно на размышлениях "как сделать лучше".
Отвлекаться — это хорошо и нормально. Это защитная реакция мозга на перегрузку. Если не будете отвлекаться, ваше тело примет более радикальные меры по защите (потеря интереса к работе, апатия, депрессия, и все такое). Самое лучшее время отвлечься — это когда вы закончили какую-то итерацию или поставили логическую точку в задаче.
А вот плохо — это когда вас отвлекают в момент максимальной концентрации. И решение здесь — не в настройке рабочего окружения, спинке стула и прочей лабуде, а в правильной организации рабочего процесса.
Удалите нахрен все мессенджеры. Это реальное зло. Пользуйтесь только мейлом для рабочих коммуникации. Во-первых, вы планируете сами когда просматривать почту и отвечать, во-вторых, ваш мейл позволяет вашему оппоненту более детально сформулировать проблему или вопрос, в-третьих, у вас остается запротоколированным весь диалог, в-четвертых, прежде чем писать мейл, в 50% случаев человек сначала попробует решить проблему или вопрос сам, тогда как по мессенджеру вас будут дергать по любому поводу.
Избавьтесь от любой бюрократии в вашем проекте и сконцентрируйтесь на коде. Если вы используете большое количество других средств, помимо вашей IDE, то стоит задуматься, что же вы в итоге производите. Треккеры, ганты, диаграммы, архитектуры, поверпоинты, UML не добавляют value вашему продукту.
Ничего не планируйте, вопреки советам автора. Ну то есть, определенный план конечно же должен быть, но не забивайте себя в жесткие рамки ежедневного или ежечасного планировщика задач, вопреки всем модным методологиям и советам автора. Это контрпродуктивно. Когда основным мотивом становится закрыть вовремя таск, работа делается долго и херово.
Шлите лесом всех трейнеров и коучеров, топящих за "эффективность". Иногда таким образом они пытаются разрешить внутренний конфликт, оправдывая ощущение собственной несостоятельности. Все люди разные. Что для одного хорошо — для другого окажется смерти подобно.
Хочу выразить огомное спасибо Jetbrains за мегакрутой шрифт! По началу, как это всегда бывает, сложно соскочить с привычного шрифта. Но вот сижу уже неделю, и реально торчу от читабельности и удобства. Шрифт очень сбалансирован, визуально хорошо отделяет слова, отличные лигатуры для типичных синтаксических конструкций, одинаково хорошо смотрится как на Windows, так и на Linux. Размер 12pt/1.0 вполне устраивает.
Да потому-что любой стандарт как правило убог и не покрывает большинства реальных кейсов. Конкретно о записях — перечитайте параграф "Цели, которых не было". Истинная цель появления записей в джаве скорей всего — это впоследствии прикрутить pattern matching. А моделировать данные с записями невозможно.
Впечатлило. А как на яхте правильно войти в территориальную зону? Нужно изначально согласовывать маршрут или береговая охрана запрашивается по ходу? Как обстоят дела с "парковкой" яхты? Кое-где встать не дадут — только в определенных местах, а там место стоит денег...
Плох тем, что большой latency, поэтому и не годится в сценариях, где месседжи приходят достаточно редко, но требуют моментальной обработки. Впринципе LISTEN/NOTIFY как раз мог бы использоваться для нотификации, что в такую-то очередь пришло сообщение и надо его прочитать. Но проблема в том, что стандартный PG jdbc не умеет нотификации (только через тот же поллинг).
Поэтому прежде чем заявлять, что Postgresql умеет очереди, нужно позаботиться о клиентских интерфейсах и имплементировать стандартные протоколы типа AMQP, MQTT, STOMP, JMS, etc (например в Oracle идет поддержка JMS из коробки). А на коленках через полинг я очереди могу сделать и через обычную таблицу — для этого не нужен PgQ.
Пардон, а как сие чудо использовать клиенту? Например как устроить листенер месседжей через стандартный jdbc, чтобы он не делал тупой полинг? Да и зачем так усложнять, если уже есть LISTEN/NOTIFY?
Самый лучший способ разработки — линейный, без веток, потому как самый простой. Усложнения появляются лишь по мере необходимости, а не потому, что это круто и модно. Все заморочки вокруг кода не добавляют ценности продукту, и платить за них клиент не будет.
Ну, одно время было что-то подобное ввиде JQuery. Но сейчас в экосистеме JS любая stdlib просуществует не дольше месяца, пока очередной школьник ни накропает свою с блекджеком и пр...
Да, и очень часто бизнес логика напрямую завязана на состояние коннекшна. Например показать юзеру его пинг, или показать в чате, что игрок реконнетится. На сервере для реконнектов нужно контролировать тайманты на сессию, а также уметь жестко дисконнектить клиента. А еще нужно уметь настраивать коннекшн на более низком уровне (tcp_nodelay, keep_alive, send/receive buffer, etc...), защищаться от разного рода атак на ресурсы, напр. контролировать количество коннектов на клиента, или организовывать delay-пулы против overload-а. Все это становится недоступно при использовании абстрактных надстроек более высокого уровня.
Всегда проще написать свой велосипед, понятный и заточенный под конкретную задачу, чем разбираться в абстрактном мультифункциональном протоколе, ломать голову как с помощью него реализовать необходимое, бороться с ограничениями в дизайне, а затем на проде ловить лютый гемор по поводу неучтенных нюансов в поведении провайдера и низлежащих протоколов.
Есть другая либа SockJS, которая эмулирует вебсокет с разными транспортами. В отличие от socket.io, заточена под разные бэкенды. Для джавистов есть Atmosphere Framework, который я пробовал юзать.
Тем не менее на реальном проде использование транспортных врапперов отнюдь не так хорошо, как кажется — вылезают такие кейсы, которые и не снились. Требуется спуск на уровень на транспортный уровень, который вы уже не контролируете, либо библиотека недостаточно гибкая, чтобы покрыть этот кейс. Особенно актуально на мобильной связи. Поэтому, начиная с какого-то момента, требуется разработка собственного протокола с использованием голого вебсокета или лонгполлинга.
Music: Mantis — Quincas Moreira. Не за что.
Безусловно интересно, полезно и познавательно знать, как все устроено под капотом, и какие решения по оптимизации существуют. Но реальные кейсы, где это реально необходимо, очень специфичны и малочисленны. Одно время Шипилев своими докладами породил целый класс "борцов за перформанс", которые бенчили все, что ни попадя, и не давали закрыть тикет только потому, что у куска кода сложность не O(n), а O(n²), когда реально n не превышало 10. Я лично почти не встречал острой необходимости оптимизации java-кода — все перформансные накладки были либо в изначально плохой архитектуре решения, либо в базе данных.
Если вы уперлись в предел масштабирования, то в этих случаях и перформансная оптимизация сильно не поменяет погоды. Я имею ввиду все то, о чем балаболят на конференциях — покрутить такие-то настройки JVM, заменить один объект на другой, отрефакторить такой-то кусок, и тому подобное. Там уже требуются серьезные архитектурные изменения, которые затрагивают всю систему целиком. А вот рыхлить уже работающий и отлаженный бизнес-компонент там, где общая архитектура еще позволяет масштабировть, ради прибавки в 10-15% — всегда дешевле и проще просто докупить железа.
О! Мясо!
Ровно таким же принципом руководствуется большинство девелоперов, который можно перефразировать как: "машина мощная — справится". Почему так: потому что единственной целью на сегодняшний день в разработке является эффективность: сделать максимум при минимуме затрат. Никто не заинтересован тратить время (и деньги) не только для оптимизации программы, но мало-мальски на изучение и овладение релевантными средствами разработки. Зачем? Запихнем все в браузер, запакуем сам браузер и дело в шляпе! Все накладки с производительностью будут решены в завтрашнем более мощном железе. Такие девелоперы забывают лишь одно — за ограниченные ресурсы железа борется одновременно сразу куча таких же пухлых приложений.
А дело тут не в быстроте. В далеких 90-х Word и Excel запускались на 4M и даже позволяли выполнять работу. Сегодня мощности железа возросли в тысячи раз, потребности того же оффиса — в сотни, но самое главное — функционал — грубо говоря, лишь в разы.
Дык и сейчас так, если у тебя телефону пару лет. Причем, одни и те же приложения когда-то не тупили на старом телефоне. Теперь и на нынешнем тупят. И так постоянно. Очено наглядный пример — GMail.
Потому что в Java уже больше не о чем говорить. Это либо новые фишки в JDK N+1, либо вездессущий Spring Boot, либо перформанс. Хотя там, где живет Java, любое перформансное просаживание легко решается докупкой железа.
Поэтому вместо чтобы разобраться с QT берем Электрон со встроенным браузером и херачим на джаваскрипте весь GUI и всю логику. Вместо того, чтобы критические части писать на C/C++ берем Python и вперед! Железо мощное — справится! А юзер миллионер — раскошелится!
В Италии и Испании тоже с этого началось… Поначалу тоже был вопрос, как они заставят людей с местным уровнем пофигизма сидеть дома. А вот заставили.
Для меня и многих это тоже большой вопрос. Кроме того мое мнение, что отсутствие продуктов в супермаркетах вовсе не связано с перебоями в снабжении. Просто у всех сетей уже давно просчитана вся логистика на основании статистики потребления и на этой основе заключены контракты с поставщиками и внутренние процессы производства. Поэтому система не приспособлена даже к небольшим, но резким перепадам в спросе.
Привет из Мадрида! Тоже всей семьей заперты на "удаленке" — благо наши компании ее уже давно практикуют, и вся инфраструктура налажена. Детям раздают задания по вебу и ватсапу, задания они отправляют на электронную почту школы. На улицах полиция контролирует передвижения, за неподчинение требованиям — штраф €1500. Все закрыто. В меркадону на входе очередь, квоты на продукты, полки полупустые… Самые ходовые продукты — мясо, молоко, макароны, бобовые, овощи и сортирная бумага.
Верно ли то же самое, если все апдейты делаются в одной транзакции? То есть реально новая запись делается при каждом апдейте, или же делается одна финальная запись при commit-е?
По большей части мнение автора, основанное в лучшем случае на субъективном опыте, а скорей всего — исключительно на размышлениях "как сделать лучше".
Отвлекаться — это хорошо и нормально. Это защитная реакция мозга на перегрузку. Если не будете отвлекаться, ваше тело примет более радикальные меры по защите (потеря интереса к работе, апатия, депрессия, и все такое). Самое лучшее время отвлечься — это когда вы закончили какую-то итерацию или поставили логическую точку в задаче.
А вот плохо — это когда вас отвлекают в момент максимальной концентрации. И решение здесь — не в настройке рабочего окружения, спинке стула и прочей лабуде, а в правильной организации рабочего процесса.
Удалите нахрен все мессенджеры. Это реальное зло. Пользуйтесь только мейлом для рабочих коммуникации. Во-первых, вы планируете сами когда просматривать почту и отвечать, во-вторых, ваш мейл позволяет вашему оппоненту более детально сформулировать проблему или вопрос, в-третьих, у вас остается запротоколированным весь диалог, в-четвертых, прежде чем писать мейл, в 50% случаев человек сначала попробует решить проблему или вопрос сам, тогда как по мессенджеру вас будут дергать по любому поводу.
Избавьтесь от любой бюрократии в вашем проекте и сконцентрируйтесь на коде. Если вы используете большое количество других средств, помимо вашей IDE, то стоит задуматься, что же вы в итоге производите. Треккеры, ганты, диаграммы, архитектуры, поверпоинты, UML не добавляют value вашему продукту.
Ничего не планируйте, вопреки советам автора. Ну то есть, определенный план конечно же должен быть, но не забивайте себя в жесткие рамки ежедневного или ежечасного планировщика задач, вопреки всем модным методологиям и советам автора. Это контрпродуктивно. Когда основным мотивом становится закрыть вовремя таск, работа делается долго и херово.
Шлите лесом всех трейнеров и коучеров, топящих за "эффективность". Иногда таким образом они пытаются разрешить внутренний конфликт, оправдывая ощущение собственной несостоятельности. Все люди разные. Что для одного хорошо — для другого окажется смерти подобно.
Хочу выразить огомное спасибо Jetbrains за мегакрутой шрифт! По началу, как это всегда бывает, сложно соскочить с привычного шрифта. Но вот сижу уже неделю, и реально торчу от читабельности и удобства. Шрифт очень сбалансирован, визуально хорошо отделяет слова, отличные лигатуры для типичных синтаксических конструкций, одинаково хорошо смотрится как на Windows, так и на Linux. Размер 12pt/1.0 вполне устраивает.
Да потому-что любой стандарт как правило убог и не покрывает большинства реальных кейсов. Конкретно о записях — перечитайте параграф "Цели, которых не было". Истинная цель появления записей в джаве скорей всего — это впоследствии прикрутить pattern matching. А моделировать данные с записями невозможно.
Впечатлило. А как на яхте правильно войти в территориальную зону? Нужно изначально согласовывать маршрут или береговая охрана запрашивается по ходу? Как обстоят дела с "парковкой" яхты? Кое-где встать не дадут — только в определенных местах, а там место стоит денег...
Я так полагаю, если фича зайдет, то следующей итерацией будет встроить в Java простенький dependency manager типа Grape в Groovy.
Плох тем, что большой latency, поэтому и не годится в сценариях, где месседжи приходят достаточно редко, но требуют моментальной обработки. Впринципе LISTEN/NOTIFY как раз мог бы использоваться для нотификации, что в такую-то очередь пришло сообщение и надо его прочитать. Но проблема в том, что стандартный PG jdbc не умеет нотификации (только через тот же поллинг).
Поэтому прежде чем заявлять, что Postgresql умеет очереди, нужно позаботиться о клиентских интерфейсах и имплементировать стандартные протоколы типа AMQP, MQTT, STOMP, JMS, etc (например в Oracle идет поддержка JMS из коробки). А на коленках через полинг я очереди могу сделать и через обычную таблицу — для этого не нужен PgQ.
Пардон, а как сие чудо использовать клиенту? Например как устроить листенер месседжей через стандартный jdbc, чтобы он не делал тупой полинг? Да и зачем так усложнять, если уже есть LISTEN/NOTIFY?