Имхо. Отлично. Приложения и должны быть одинаковыми. С одинаковым интерфейсом. С одинаковыми приемами работы. Чтобы раз и навсегда выработав привычки и набив руку, пользователь в ЛЮБОМ приложении чувствовал себя как дома. Не нужно было переучиваться в новых приложениях и ломать себя.
Так и было во временя Delphi. И это было замечательно. А потом свернули куда-то не туда и появились веб-приложения каждый со своим интерфейсом, заморочками.
Приложения ДОЛЖНЫ быть "скучными". Пользователь запускает приложение, чтобы делать что-то полезное для себя, а не развлекаться видом приложения. Терпеть не могу "осваивать" приложение.
Разработчики, и особенно, менеджеры, будут концентрироваться на пользе от приложения, а не на извращениях с интерфейсом. Изменения в интерфейсе и способах работы с приложением - это не "новое" и не фичи.
Какому "партнеру"? Супругу? С трудом понял, о чем речь.
Первый раз о такой проблематике услышал. Мы с супругой хоть и инженеры оба, но в радикально разных отраслях. С какой стати помогать супруге в работе? Она профессионал.
Если есть эта точка, значит, есть место творения. Значит размер вселенной ограничен. А раз ограничен, то есть вероятность, что вселенная - это какой-то предмет с размерами и соответственно, была создана кем-то.
Покоящегося! А нейтроны, движущиеся с околосветовой скоростью, живут НАМНОГО дольше. Во-первых, а во-вторых, 15 минут - https://ru.wikipedia.org/wiki/Время_жизни_квантовомеханической_системы, а значит ненулевое количество нейтронов может прожить и 30 минут, и миллиард лет, это дело случая.
Прочитал про VACUUM (не работаю с postgres), так вот в бытность работы с MS SQL как разработчику очень часто приходилось работать с аналогичными вещами, типа обновлением индексов, поскольку вопросы производительности от клиентов валятся на программистов.
Обижаете. Я, например, всю жизнь развивал легаси. Ни разу не начинал новый проект (кроме петов). И смею утверждать, что делаю это хорошо. И часто бывает очень интересно. И достижения на этом поприще тоже можно сделать. У меня - практически спасти проект от закрытия, поскольку на момент моего появления в команде обсуждался вопрос о закрытии проекта и начала нового по причине нарастающей лавины ошибок, "комка грязи" и невозможности развития. "Уважающие себя" разрабы (которые все это наворотили) ушли на новые проекты, в результате воткнули первого попавшего меня, не особо собеседуя. Ликвидировал все ошибки (даже клиенты отмечали улучшение), рефакторил, форматировал. В результате проект продолжил жизнь еще на десять лет.
Очень тяжелая и неприятная работа, но как говорят американцы, платят за дурно пахнущую работу.
Такшта, поддержка легаси не пугает, но как это говорить на собесах, не знаю.
Почему ScopedValue сравнивается с ThreadLocal? ThreadLocal по-сути - глобальная переменная в пределах потока. Через нее можно передавать значение в методы, минуя параметры (всякие кеши).
ScopedValue действует ограниченное время в пределах одного блока. Действие смахивает на
String v = "banana";
System.out.println(v);
{
String v = "apple"; //ERROR: variable v is already defined in method main(java.lang.String[])
System.out.println(v);
}
System.out.println(v);
В отличии от C++, такой код не скомпилируется. Поэтому, видимо, наворотили таких костылей с лямбдами.
Как будет работать f8 в идее с такими конструкциями? Будет курсор по f8 заходить в лямбду и шагать дальше?
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
И вполне себе спрашивают, как и каким образом java-код компилируется. Плюс спрашивают про управление памятью в java (а их там несколько).
Не знаю Go, но подозреваю, что в java заморочек больше. И если в "компилируемых" языках вы управляете производительностью напрямую, то в Java очень-очень опосредовательно, что очевидно не проще. А проблем с производительностью в реальных приложениях полно.
Данный пример не очень релевантный, потому что можно исхитриться без Вальгаллы.
В случае, если в классе находятся примитивы одного типа, можно организовать класс с массивом двойной длины (в данном примере) и хранить в x в четных, y в нечетных ячейках массива. Организовать get и set соответствующим образом.
Буду признателен тому, кто подскажет, как несколько int из массива преобразовать в double. Иначе говоря, как в массиве int хранить значение double, без создания объектов, как это можно делать в C.
С сортировкой, чувствую, тут обман какой-то. По идее, сортировка массива указателей на объекты должно быть быстрее, чем сортировка плоских объектов, потому что вместо четырех (в данном случае) чисел нужно менять местами только два. Образно говоря, перевешиваются "номерки", вместо "чемоданов". Возможно, играет роль доступ к элементам для сравнения.
Работодатель предпочтет менее высокооплачиваемого разработчика при тех-же требованиях к должности. Для разработки приложения с формочками и sql-запросами знание ассемблера не только не нужно, но и вредно. Насчет "душности" - руководству вообще безразлично.
Есть такой тип команд - в них невозможно никого ни о какой помощи попросить. Тебя заворачивают "ты же сам хочешь в этой проблеме разобраться". Если ты лично не дружишь с членами команды - добиться обсуждения ни по какому вопросу становится невозможным. Особенно где "у нас молодой дружный коллектив", которые сразу после универа. Там просто беда с коллаборацией. С этим дружу, с теми не дружу.
Вот для таких случаев, чтобы формализовать общение и ЗАСТАВИТЬ всех коллег участвовать в работе команды, и придуманы всякие митинги.
В нормальных взрослых коллективах все вопросики уже решены. Люди общаются, обмениваются инфой и помогают друг другу независимо от личных предпочтений и неприязни.
В промышленности распространены совещания, но там на совещании присутствуют не рядовые исполнители, а начальники цехов и отделов, которые да, докладывают поочередно о прогрессе и возможных проблемах.
Человека можно понять. Вы или низкоуровнего сишника, оптимизатора берете, либо кодера бизнес-логики.
В бизнес-приложении никто не будет смотреть на код, генерируемый компилятором и JVM. Эффект для производительности имеет только правильный выбор коллекций, алгоритмов работы с ними, стримами и грамотные sql-запросы.
Все уже придумано до нас. Минимальный набор реализован в языке Оберон. Все остальное - ненужная реализация фантазий и хотелок "я хотел бы вот эту возможность".
Смешно. "Продуктивен". В чем продуктивность? В том, что легко исправлять ошибки? Прямо на проде? Автор гордится, что в день исправлял по двадцать ошибок? Та легкость, с которой легко наворотить ошибок ("да, он не идеален") - это плюс языка? Ошибки сначала летят клиентам, а те отправляют автору отчеты со стек-трейсами "в которых можно было видеть текст кода"? Серьезно? Этому научился автор на проектах с пхп и питоном?
Сплит напрямую создает массив строк. Токенизер никаких массивов не создает. При каждом вызове getNextToken объекта токенизера возвращается слово-токен. Его можно сравнить со словом максимумом и заменить им максимум.
"Детский" в том смысле, что берется первый попавшийся, без учета внутренней работы библиотечной функции/класса.
"Взрослый" подход, когда выбирается необходимый класс/функция, четко понимая, какие алгоритмы они реализуют и как вообще работают.
Есть задачи и ситуации, когда деньги не решают ровным счетом ничего. Точнее, никакое сколь большое количество денег не способно решить задачу.
Имхо. Отлично. Приложения и должны быть одинаковыми. С одинаковым интерфейсом. С одинаковыми приемами работы. Чтобы раз и навсегда выработав привычки и набив руку, пользователь в ЛЮБОМ приложении чувствовал себя как дома. Не нужно было переучиваться в новых приложениях и ломать себя.
Так и было во временя Delphi. И это было замечательно. А потом свернули куда-то не туда и появились веб-приложения каждый со своим интерфейсом, заморочками.
Приложения ДОЛЖНЫ быть "скучными". Пользователь запускает приложение, чтобы делать что-то полезное для себя, а не развлекаться видом приложения. Терпеть не могу "осваивать" приложение.
Разработчики, и особенно, менеджеры, будут концентрироваться на пользе от приложения, а не на извращениях с интерфейсом. Изменения в интерфейсе и способах работы с приложением - это не "новое" и не фичи.
Эппл как всегда на высоте, молодцы.
Какому "партнеру"? Супругу? С трудом понял, о чем речь.
Первый раз о такой проблематике услышал. Мы с супругой хоть и инженеры оба, но в радикально разных отраслях. С какой стати помогать супруге в работе? Она профессионал.
Если есть эта точка, значит, есть место творения. Значит размер вселенной ограничен. А раз ограничен, то есть вероятность, что вселенная - это какой-то предмет с размерами и соответственно, была создана кем-то.
Покоящегося! А нейтроны, движущиеся с околосветовой скоростью, живут НАМНОГО дольше. Во-первых, а во-вторых, 15 минут - https://ru.wikipedia.org/wiki/Время_жизни_квантовомеханической_системы, а значит ненулевое количество нейтронов может прожить и 30 минут, и миллиард лет, это дело случая.
Прочитал про VACUUM (не работаю с postgres), так вот в бытность работы с MS SQL как разработчику очень часто приходилось работать с аналогичными вещами, типа обновлением индексов, поскольку вопросы производительности от клиентов валятся на программистов.
Обижаете. Я, например, всю жизнь развивал легаси. Ни разу не начинал новый проект (кроме петов). И смею утверждать, что делаю это хорошо. И часто бывает очень интересно. И достижения на этом поприще тоже можно сделать. У меня - практически спасти проект от закрытия, поскольку на момент моего появления в команде обсуждался вопрос о закрытии проекта и начала нового по причине нарастающей лавины ошибок, "комка грязи" и невозможности развития. "Уважающие себя" разрабы (которые все это наворотили) ушли на новые проекты, в результате воткнули первого попавшего меня, не особо собеседуя. Ликвидировал все ошибки (даже клиенты отмечали улучшение), рефакторил, форматировал. В результате проект продолжил жизнь еще на десять лет.
Очень тяжелая и неприятная работа, но как говорят американцы, платят за дурно пахнущую работу.
Такшта, поддержка легаси не пугает, но как это говорить на собесах, не знаю.
Почему ScopedValue сравнивается с ThreadLocal? ThreadLocal по-сути - глобальная переменная в пределах потока. Через нее можно передавать значение в методы, минуя параметры (всякие кеши).
ScopedValue действует ограниченное время в пределах одного блока. Действие смахивает на
В отличии от C++, такой код не скомпилируется. Поэтому, видимо, наворотили таких костылей с лямбдами.
Как будет работать f8 в идее с такими конструкциями? Будет курсор по f8 заходить в лямбду и шагать дальше?
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
И вполне себе спрашивают, как и каким образом java-код компилируется. Плюс спрашивают про управление памятью в java (а их там несколько).
Не знаю Go, но подозреваю, что в java заморочек больше. И если в "компилируемых" языках вы управляете производительностью напрямую, то в Java очень-очень опосредовательно, что очевидно не проще. А проблем с производительностью в реальных приложениях полно.
Данный пример не очень релевантный, потому что можно исхитриться без Вальгаллы.
В случае, если в классе находятся примитивы одного типа, можно организовать класс с массивом двойной длины (в данном примере) и хранить в x в четных, y в нечетных ячейках массива. Организовать get и set соответствующим образом.
Буду признателен тому, кто подскажет, как несколько int из массива преобразовать в double. Иначе говоря, как в массиве int хранить значение double, без создания объектов, как это можно делать в C.
Первая женщина-робот, побывавшая (чуть не долетела, но все-же) в космосе. Ну не целиком женщина, но все-же.
С сортировкой, чувствую, тут обман какой-то. По идее, сортировка массива указателей на объекты должно быть быстрее, чем сортировка плоских объектов, потому что вместо четырех (в данном случае) чисел нужно менять местами только два. Образно говоря, перевешиваются "номерки", вместо "чемоданов". Возможно, играет роль доступ к элементам для сравнения.
Что лучше - разраб, который быстро пишет ахинею, или разраб, который пишет медленно, но хорошо?
Так оказывается, это собеседование...
А я думал, это такой способ унижения и подчинения.
Работодатель предпочтет менее высокооплачиваемого разработчика при тех-же требованиях к должности. Для разработки приложения с формочками и sql-запросами знание ассемблера не только не нужно, но и вредно. Насчет "душности" - руководству вообще безразлично.
Есть такой тип команд - в них невозможно никого ни о какой помощи попросить. Тебя заворачивают "ты же сам хочешь в этой проблеме разобраться". Если ты лично не дружишь с членами команды - добиться обсуждения ни по какому вопросу становится невозможным. Особенно где "у нас молодой дружный коллектив", которые сразу после универа. Там просто беда с коллаборацией. С этим дружу, с теми не дружу.
Вот для таких случаев, чтобы формализовать общение и ЗАСТАВИТЬ всех коллег участвовать в работе команды, и придуманы всякие митинги.
В нормальных взрослых коллективах все вопросики уже решены. Люди общаются, обмениваются инфой и помогают друг другу независимо от личных предпочтений и неприязни.
В промышленности распространены совещания, но там на совещании присутствуют не рядовые исполнители, а начальники цехов и отделов, которые да, докладывают поочередно о прогрессе и возможных проблемах.
Человека можно понять. Вы или низкоуровнего сишника, оптимизатора берете, либо кодера бизнес-логики.
В бизнес-приложении никто не будет смотреть на код, генерируемый компилятором и JVM. Эффект для производительности имеет только правильный выбор коллекций, алгоритмов работы с ними, стримами и грамотные sql-запросы.
Все уже придумано до нас. Минимальный набор реализован в языке Оберон. Все остальное - ненужная реализация фантазий и хотелок "я хотел бы вот эту возможность".
Смешно. "Продуктивен". В чем продуктивность? В том, что легко исправлять ошибки? Прямо на проде? Автор гордится, что в день исправлял по двадцать ошибок? Та легкость, с которой легко наворотить ошибок ("да, он не идеален") - это плюс языка? Ошибки сначала летят клиентам, а те отправляют автору отчеты со стек-трейсами "в которых можно было видеть текст кода"? Серьезно? Этому научился автор на проектах с пхп и питоном?
Сплит напрямую создает массив строк. Токенизер никаких массивов не создает. При каждом вызове getNextToken объекта токенизера возвращается слово-токен. Его можно сравнить со словом максимумом и заменить им максимум.
"Детский" в том смысле, что берется первый попавшийся, без учета внутренней работы библиотечной функции/класса.
"Взрослый" подход, когда выбирается необходимый класс/функция, четко понимая, какие алгоритмы они реализуют и как вообще работают.