В принципе с GPIO из Java можно работать как с обычными файлами. А Pi4J без поддержки 1-wire довольно бесполезен, даже простой термодатчик не повесить.
Ещё вопрос по GPIO, может кто поможет? У Raspbian'а не хватает одного модуля для работы 1-wire почему-то, который есть в других сборках. Исходники я нашёл, а вот как собрать и добавить в ядро я не знаю, OS я знаю только как пользователь. Может быть кто-то может помочь? Я тогда напишу подробнее.
У лампы накаливания критическим соотношением является время работы/эффективность. КПД такой лампы около 5% и сильно зависит от температуры, при повышении температуры время работы быстро сокращается. Снизив температуру можно увеличить срок службы, но это скажется на КПД, и вы можете потерять 5 киловатт*часов например, что может оказаться дороже новой лампочки
На самом деле всё это уже проходили в других областях, например электротехнике. Сто лет назад электрификация — это был hi tech, и инженер должен был всё знать электричестве. А сейчас роли разделились: есть инженер-электротехник, и есть электрик. Если первому необходимо высшее образование, то второму среднего специального достаточно с головой. В этом нет ничего плохого, инженер проектирует, электрик монтирует. IT развивается, и со временем большинство программистов будут уровня электрик-сантехник, собирающими типовое приложение на базе готовых модулей. Но останутся и задачи по разработке чего-то нового и сложного.
По этому Россия и была до недавнего времени единственной странной в мире, куда Амазон вообще не отправлял посылки. (Был как-то на загнивающющем по работе, заказал ноут, так его почтальон под дверью оставил, и ничего, дождался меня с работы)
Я когда-то, как и вы, работал над трекингом задач в относительно большой компании. Трекер так же был иерархическим, похожим на ваш, он работал, но возникал ряд проблем.
Самая важная — по какому принципу строить иерархию? Например задачи можно объединить по проекту, а можно по исполнителям. Внутри проекта, например, по релизам, или по модулям, и т.д. Принципов группировки может быть очень много, и определённый момент определённому человеку нужен только один, а другие бесполезны. Так что фактически ваша иерархия никому не нужна, а показывать нужно ту структуру, которая нужна в данный момент. Мы называли это досками, у каждой доски был свой пользователь и своя структура. Например «Мои текущие задания» — это очередь входящих заданий в порядке приоритета выполнения + список задач в работе.
Ещё вы не затронули тему планирование выполнения задач. При высокой нагруженности людей сложно предсказать, когда какая задача будет сделана, а для планирования деятельности это очень важно. Если вас это ещё ждёт впереди, то сделаю подсказку: имея ваши инструменты скорее всего возникнет желание для каждой задачи назначить время выполнения, а это путь в никуда.
У вас завязалась интересная дискуссия :) Антон, почему вы уверены, что по закону — это обязательно правильно? Законы у нас принимают отдельные люди, и не всегда они логичны и всё учитывают.
Начнём с налогов. У нас налог(соцстрах + подоходный + ндс) забирает ровно половину дохода человека. Половину! Я вправе ожидать каких-то результатов за эти деньги, но приведу пример. У меня во дворе снег убирали за зиму 2 раза, и то только сверху счистили, до асфальта сантиметров 10 укатанного снега. Снег сгребали в гору прямо перед подъездом, приходилось лазить через него. Умер у меня сосед, его вынести не могли, попросили в ЖЭСе убрать гору. Убрали, но на следующий день пришли требовать деньги за уборку! Думаю каждый приведёт множество подобных примеров.
Такая проблема от того, что у нас традиционно налог — это дань. Дань лично руководителю, и он вправе тратить её как хочет. Например хочет — купит себе машину за $200k, с мигалкой, чтобы гонять тех, кто ему эту дань платит. А дань традиционно нужно забирать силой, по своей воле никто её никогда не платил. И пока будет такое отношение, все будут избегать этой дани любыми способами. Вы конечно можете относиться с этому по-другому и платить налоги, но ситуацию в целом это не поменяет.
Что касается миграции, внутри страны или от ближайших соседей, то к этому вопросу можно относиться по разному. С одной стороны как можно запрещать людям переезжать? Это ведь не тюрьма, если люди хотят уехать — это их право. С другой стороны — если к нам хотят приехать люди, которые нам не нравятся, мы имеем право их не пустить, ведь это наш дом.
Так вот ключевым вопросом будет: кто и как будет определять, пускать новых людей или нет? Сейчас ни в законах, ни в сознании людей нет чётких ответов на этот вопрос. Есть какие-то бюрократические препятствия, но они не селективны. Нет чёткого ответа — нужен конкретно этот мигрант городу или нет? Вам например нет, а ЖЭСу нужен. Если он прошёл квест с регистрацией, то вроде всё как бы и по закону. Но чем он от этого стал нужнее или лучше?
Извините, мне страшно представить, как вы живёте в таких условиях. Почему вы не уедете из Москвы? Я серьёзно, ведь IT не так жёстко привязывает к месту жительства. Что вас держит?
Синхронизация и volatile несут несколько различный смысл.
Думаю, что volatile значительно улучшило бы ситуацию в случае инкремента. Без volatile переменная может кэшироваться в потоке. Т.е. есть вероятность, что переменная обнулится из другого потока, а мы не заметим, и присвоим ей {старое значение + 1}.
Но, теоретически, между чтением и записью переменная всё равно может быть изменена другим потоком. Наиболее вероятно это между подсчётом скорости и обнулением, т.к. там несколько операций выполняется. Поэтому для полной уверенности нужно синхронизировать блок от чтения до записи.
Это похоже на вызов :) Я не могу не ответить.
Вам не кажется глупым ради обнуления счётчика городить синхронизацию? Ведь самое страшное, что может произойти — мы недосчитаемся цитаты при подсчёте скорости.
Тогда уж больше опасность представляет чтение этих переменных, они ведь не объявлены volatile, и результат может быть устаревшим.
Вы уверены, что нужно уделять столько внимания вспомогательной функциональности? Вероятность ошибки ведь очень низкая.
Использование time.Sleep обсуждали в этой ветке комментариев. Если я правильно понял, это нужно для того, чтобы дать возможность выполниться основному потоку. Но в моём случае это не нужно, т.к. я явно указал приоритет worker.setPriority(2). Чтобы сохранить дословность пересказа, можно использовать Thread.sleep(100), но лучше подойдёт Thread.yield() — он переместит поток в конец очереди планировщика без задержки.
О смысле статью расскажу подробнее. Я работаю с Java относительно давно, и в целом уже нормально разобрался, а о Go только слышал, но довольно много. Мне стало интересно, стоит ли бросать Java и переходить на более современный Go? Поэтому я и решил их сравнить на этой задаче. Как вывод скажу, что Go моложе и что-то в нём сделано удобнее, и если вы не знаете ни того ни другого, то возможно лучше выбрать Go. Но Java пока держится, хоть и некоторые решения выглядят как костыли, например аннотации. И имея опыт в Java пока рано её бросать.
Думаю в этой задаче разница будет не заметна, скорость будет определяться внешними факторами: открытием страниц и записью на диск. Но попробовать можно, правда у меня интернет не очень, могу только предложить jar для теста.
Моё субъективное мнение: скорость — это не главное. В крупном приложении скорость определяется архитектурой. На много важнее, чтобы приложение работало правильно и легко изменялось.
Ещё вопрос по GPIO, может кто поможет? У Raspbian'а не хватает одного модуля для работы 1-wire почему-то, который есть в других сборках. Исходники я нашёл, а вот как собрать и добавить в ядро я не знаю, OS я знаю только как пользователь. Может быть кто-то может помочь? Я тогда напишу подробнее.
Самая важная — по какому принципу строить иерархию? Например задачи можно объединить по проекту, а можно по исполнителям. Внутри проекта, например, по релизам, или по модулям, и т.д. Принципов группировки может быть очень много, и определённый момент определённому человеку нужен только один, а другие бесполезны. Так что фактически ваша иерархия никому не нужна, а показывать нужно ту структуру, которая нужна в данный момент. Мы называли это досками, у каждой доски был свой пользователь и своя структура. Например «Мои текущие задания» — это очередь входящих заданий в порядке приоритета выполнения + список задач в работе.
Ещё вы не затронули тему планирование выполнения задач. При высокой нагруженности людей сложно предсказать, когда какая задача будет сделана, а для планирования деятельности это очень важно. Если вас это ещё ждёт впереди, то сделаю подсказку: имея ваши инструменты скорее всего возникнет желание для каждой задачи назначить время выполнения, а это путь в никуда.
Начнём с налогов. У нас налог(соцстрах + подоходный + ндс) забирает ровно половину дохода человека. Половину! Я вправе ожидать каких-то результатов за эти деньги, но приведу пример. У меня во дворе снег убирали за зиму 2 раза, и то только сверху счистили, до асфальта сантиметров 10 укатанного снега. Снег сгребали в гору прямо перед подъездом, приходилось лазить через него. Умер у меня сосед, его вынести не могли, попросили в ЖЭСе убрать гору. Убрали, но на следующий день пришли требовать деньги за уборку! Думаю каждый приведёт множество подобных примеров.
Такая проблема от того, что у нас традиционно налог — это дань. Дань лично руководителю, и он вправе тратить её как хочет. Например хочет — купит себе машину за $200k, с мигалкой, чтобы гонять тех, кто ему эту дань платит. А дань традиционно нужно забирать силой, по своей воле никто её никогда не платил. И пока будет такое отношение, все будут избегать этой дани любыми способами. Вы конечно можете относиться с этому по-другому и платить налоги, но ситуацию в целом это не поменяет.
Что касается миграции, внутри страны или от ближайших соседей, то к этому вопросу можно относиться по разному. С одной стороны как можно запрещать людям переезжать? Это ведь не тюрьма, если люди хотят уехать — это их право. С другой стороны — если к нам хотят приехать люди, которые нам не нравятся, мы имеем право их не пустить, ведь это наш дом.
Так вот ключевым вопросом будет: кто и как будет определять, пускать новых людей или нет? Сейчас ни в законах, ни в сознании людей нет чётких ответов на этот вопрос. Есть какие-то бюрократические препятствия, но они не селективны. Нет чёткого ответа — нужен конкретно этот мигрант городу или нет? Вам например нет, а ЖЭСу нужен. Если он прошёл квест с регистрацией, то вроде всё как бы и по закону. Но чем он от этого стал нужнее или лучше?
Думаю, что volatile значительно улучшило бы ситуацию в случае инкремента. Без volatile переменная может кэшироваться в потоке. Т.е. есть вероятность, что переменная обнулится из другого потока, а мы не заметим, и присвоим ей {старое значение + 1}.
Но, теоретически, между чтением и записью переменная всё равно может быть изменена другим потоком. Наиболее вероятно это между подсчётом скорости и обнулением, т.к. там несколько операций выполняется. Поэтому для полной уверенности нужно синхронизировать блок от чтения до записи.
Вам не кажется глупым ради обнуления счётчика городить синхронизацию? Ведь самое страшное, что может произойти — мы недосчитаемся цитаты при подсчёте скорости.
Тогда уж больше опасность представляет чтение этих переменных, они ведь не объявлены volatile, и результат может быть устаревшим.
Вы уверены, что нужно уделять столько внимания вспомогательной функциональности? Вероятность ошибки ведь очень низкая.
О смысле статью расскажу подробнее. Я работаю с Java относительно давно, и в целом уже нормально разобрался, а о Go только слышал, но довольно много. Мне стало интересно, стоит ли бросать Java и переходить на более современный Go? Поэтому я и решил их сравнить на этой задаче. Как вывод скажу, что Go моложе и что-то в нём сделано удобнее, и если вы не знаете ни того ни другого, то возможно лучше выбрать Go. Но Java пока держится, хоть и некоторые решения выглядят как костыли, например аннотации. И имея опыт в Java пока рано её бросать.
Моё субъективное мнение: скорость — это не главное. В крупном приложении скорость определяется архитектурой. На много важнее, чтобы приложение работало правильно и легко изменялось.