Меня как то заподозрили в сабже, к счастью, снимки показали, что это не так. Но надо проверяться.
Так вот, конкретно эта фотография вызвала у меня положительные эмоции — «роговицу удалось укрепить».
Про десктопный софт на своем ПК ничего путного сказать не могу. Кроме IDE не использую.
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит embedded jre. Просто зазипованная папка, распаковать и запустить.
IDE vs VIM vs emacs vs whatsoever — спор неблагодарный и бесполезный, да. Для руби я использую текстовый редактор (ide лишь раздражает), для явы мне удобнее IDE.
Обратная совместимость есть. Сравнить особо не с чем. Слышал что у .NET с этим проблемы.
По поводу статей. Прогресс действительно есть, со временем совершенствуются GC, JIT-компилятор.
Когда я свитчнулся на руби, то слышал просто огромное количество критики от людей, которые с явой никогда не имели дело, кроме запуска каких нибудь чужих кривых десктопных программ. При этом у Ruby в то время были гораздо большие проблемы с производительностью, да и Ruby VM тоже имет GC (куда более простенький и гораздо менее настраиваемый) и склонность пожирать память. Просто CRUD-овые вебаппы ее много не едят, в принципе. Был опыт, когда нужна была обработка большого количества сильно связанных сущностей, rake таск на руби потреблял память сотнями МБ в сек.
Еще момент, яву все же нужно уметь готовить. Если бы большинство тех самых кривопрограмм ограничили heap до какого то приемлемого объема и настроили heap ratio так, чтобы jvm возвращала освобожденную память системе, возможно не было бы такой репутации, что ява требует ОЧЕНЬ много памяти. Впрочем, конечному пользователю это не очень интересно. Да и десктопный софт как явление помирает, чего его пинать лишний раз.
Как-то уж совсем конкретно подходите) Лучше конечно сначала было бы замерить, но речь не о том.
Java на сервере мне нравится за:
а) легкость деплоя — поставил пакет java8, запустил java -jar… Об этом упоминается в статье. С руби, например все не так гладко… А с другой стороны, программе на голанг и пакеты не нужны) Один бинарник.
б) экосистема. Много зрелых библиотек с хорошей документацией.
Мне понадобилась реализация протокола CoAP, самой полной и проработанной оказалась реализация на Java. Экономия сил и времени. А 1 млрд строк за миллисекунды мне обрабатывать не надо) Мне бы быстрее сервер в строй ввести.
в) JVM языки. Мешает статика? Groovy, Kotlin, JRuby. У меня есть двуязычный проект Java + Groovy, практически бесшовно стыкуются. Правда, проникшись идеями тов. Егора Бугаенко, груви в последнее время выпиливаю… А вот для DSL самое то.
г) IDEA действительно хороша для Java (эх, если бы еще не некоторое количество глюков..)
д) какое-то время назад надо было написать незатейливый, но кроссплатформенный десктопный клиент.
Проще всего мне было написать на Java FX. Скорее всего это только из-за того, что я знаком с Java.
Где-то 10 марта наблюдал Венеру в x50 зрительную трубу на юге Кировской обл.
В первый раз увидел ее серп своими глазами (хоть и через трубу).
Показалось, что серп был расположен почти горизонтально, острыми концами вверх.И он был потолще чем на фото.
>> опыт, полученный горькими слезами и днями/неделями в поисках решения
Мы видимо в каких-то очень разных реалиях живем, если у вас есть на дни и недели(!) возможность. У вас есть вакансии?)
Фронтендом не занимаетесь видимо? Локальная справка, хах))
Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.
Я думаю, без интернета программировать возможно, если вы скажем программируете под голый attiny13 и заучили все наизусть. Ну или у вас абсолютно core java, скаченный javadoc и сферические задачи в вакууме. И никакой интеграции с внешними системами.
А еще абсолютно безглючная ОС и средства разработки.
И все же это болометрическая матрица, а не обычная камера без ИК-фильтра (коими являются так называемые ИК-камеры, способные работать только с подсветкой). А болометры не дешевы, да.
Даже в лесу, где есть сотовое покрытие — не ахти удобно говорить по хрупкому куску стекла за 20-60 т.р. без каких либо кнопок, где для осуществления связи нужно проделать массу телодвижений к тому же. Особенно если руки заняты. И абонентов более 2-х.
Пара вопросов.
Не обязательно автору, может кто знает:
1) Если например, у меня SaaS, и иностранцы, скажем, купили 20 подписок. Платежный посредник прислал мне деньги на р/c. Что тут является первичкой для налоговой?
Автору:
2) Вывод на р/с осуществляется от российской компании? А то был у payoneer вывод через wire transfer, в рублях. Такие платежи все равно подлежали валютному контролю, т.к. производились от ирландской компании.
3) Непонятно про вывод твердой валюты. Если она выводится на р/c, то от резидента резиденту такие платежи запрещены. Если от нероссийской, то нужны документы для валютного контроля. Контракт и какой-нибудь документ типа инвойса. Вы получается, такие документы эпредоставляете? Не совсем понятно, как может выглядеть такой контракт.
С момента выхода этой статьи в оригинальном блоге, наблюдаю за спорами по ее поводу.
Одна сторона полностью согласна, аргументируя, что это в работе все равно не потребуется, другая утверждает, что некоторый отсев алгоритмами таки нужен.
Мне неоднократно приходилось в рабочих задачах обходить деревья в ширину и в высоту (проекты довольно обыкновенные), и я думаю, что такого рода задачки на собеседованиях не так уж и бессмысленны. Просто во всем должна быть мера. Я вот с ходу не сбалансирую RB-дерево. Мне оно не нужно в повседневной работе.
А еще с одной стороны, зачем же нужно это делать на бумажке или доске? Задачки уровня fizzbuzz то еще вполне, но что-то сложное — а зачем? Какой в этом смысл? Мне придется и в дальнейшем, на работе, программировать на бумажке? Или хотя бы на доске?)
Вопрос по AND с КДПВ. У меня точно такой же, в инструкции написано что надо с закрытой крышкой приставить ко лбу, нажать кнопку и провести по всему лбу. Результат всегда разный. В ухе без крышки более менее одинаковый вроде бы. Как правильно пользоваться?
В итоге пользуюсь более дешевым контактным (показанию полностью совпадают с ртутным), т.к. не доверяю этому… Но надо ждать 4 минуты.
Так вот, конкретно эта фотография вызвала у меня положительные эмоции — «роговицу удалось укрепить».
Уточню сразу, не сарказм и не наезд, вполне искренний интерес.
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит embedded jre. Просто зазипованная папка, распаковать и запустить.
IDE vs VIM vs emacs vs whatsoever — спор неблагодарный и бесполезный, да. Для руби я использую текстовый редактор (ide лишь раздражает), для явы мне удобнее IDE.
Обратная совместимость есть. Сравнить особо не с чем. Слышал что у .NET с этим проблемы.
По поводу статей. Прогресс действительно есть, со временем совершенствуются GC, JIT-компилятор.
Когда я свитчнулся на руби, то слышал просто огромное количество критики от людей, которые с явой никогда не имели дело, кроме запуска каких нибудь чужих кривых десктопных программ. При этом у Ruby в то время были гораздо большие проблемы с производительностью, да и Ruby VM тоже имет GC (куда более простенький и гораздо менее настраиваемый) и склонность пожирать память. Просто CRUD-овые вебаппы ее много не едят, в принципе. Был опыт, когда нужна была обработка большого количества сильно связанных сущностей, rake таск на руби потреблял память сотнями МБ в сек.
Еще момент, яву все же нужно уметь готовить. Если бы большинство тех самых кривопрограмм ограничили heap до какого то приемлемого объема и настроили heap ratio так, чтобы jvm возвращала освобожденную память системе, возможно не было бы такой репутации, что ява требует ОЧЕНЬ много памяти. Впрочем, конечному пользователю это не очень интересно. Да и десктопный софт как явление помирает, чего его пинать лишний раз.
Java на сервере мне нравится за:
а) легкость деплоя — поставил пакет java8, запустил java -jar… Об этом упоминается в статье. С руби, например все не так гладко… А с другой стороны, программе на голанг и пакеты не нужны) Один бинарник.
б) экосистема. Много зрелых библиотек с хорошей документацией.
Мне понадобилась реализация протокола CoAP, самой полной и проработанной оказалась реализация на Java. Экономия сил и времени. А 1 млрд строк за миллисекунды мне обрабатывать не надо) Мне бы быстрее сервер в строй ввести.
в) JVM языки. Мешает статика? Groovy, Kotlin, JRuby. У меня есть двуязычный проект Java + Groovy, практически бесшовно стыкуются. Правда, проникшись идеями тов. Егора Бугаенко, груви в последнее время выпиливаю… А вот для DSL самое то.
г) IDEA действительно хороша для Java (эх, если бы еще не некоторое количество глюков..)
д) какое-то время назад надо было написать незатейливый, но кроссплатформенный десктопный клиент.
Проще всего мне было написать на Java FX. Скорее всего это только из-за того, что я знаком с Java.
В первый раз увидел ее серп своими глазами (хоть и через трубу).
Показалось, что серп был расположен почти горизонтально, острыми концами вверх.И он был потолще чем на фото.
Мы видимо в каких-то очень разных реалиях живем, если у вас есть на дни и недели(!) возможность. У вас есть вакансии?)
Фронтендом не занимаетесь видимо? Локальная справка, хах))
Кстати говоря, это был не совсем сарказм. Иногда весь стек под контролем разработчика, да. Но теперь уж очень редко.
А еще абсолютно безглючная ОС и средства разработки.
Не обязательно автору, может кто знает:
1) Если например, у меня SaaS, и иностранцы, скажем, купили 20 подписок. Платежный посредник прислал мне деньги на р/c. Что тут является первичкой для налоговой?
Автору:
2) Вывод на р/с осуществляется от российской компании? А то был у payoneer вывод через wire transfer, в рублях. Такие платежи все равно подлежали валютному контролю, т.к. производились от ирландской компании.
3) Непонятно про вывод твердой валюты. Если она выводится на р/c, то от резидента резиденту такие платежи запрещены. Если от нероссийской, то нужны документы для валютного контроля. Контракт и какой-нибудь документ типа инвойса. Вы получается, такие документы эпредоставляете? Не совсем понятно, как может выглядеть такой контракт.
Одна сторона полностью согласна, аргументируя, что это в работе все равно не потребуется, другая утверждает, что некоторый отсев алгоритмами таки нужен.
Мне неоднократно приходилось в рабочих задачах обходить деревья в ширину и в высоту (проекты довольно обыкновенные), и я думаю, что такого рода задачки на собеседованиях не так уж и бессмысленны. Просто во всем должна быть мера. Я вот с ходу не сбалансирую RB-дерево. Мне оно не нужно в повседневной работе.
А еще с одной стороны, зачем же нужно это делать на бумажке или доске? Задачки уровня fizzbuzz то еще вполне, но что-то сложное — а зачем? Какой в этом смысл? Мне придется и в дальнейшем, на работе, программировать на бумажке? Или хотя бы на доске?)
В итоге пользуюсь более дешевым контактным (показанию полностью совпадают с ртутным), т.к. не доверяю этому… Но надо ждать 4 минуты.