ну давай посчитаем. поставил ты светильник на 50ватт. что вполне себе хватает для небольшой площади. даже если каждый день светить по 12 часов(в реальности так никто делать не будет, ибо летом солнца хватает) то получается набегает 219 киловатт. при стоимости в 5.38 рублей за квт/ч для Москвы это будет аж 1178 рублей в год! А в месяц 100 рублей.Это дорого?
У нас электричество не космических денег стоит. Понятное дело что растить на лампе накаливания я не предлагаю, но ЭСЛ вполне. Другой вопрос — тепло. При низких показателях светоотдачи все остальное уходит в тепло и это проблема. Проблема нагрева бокса. Для диодов это еще бОльшая проблема ибо при поднятии температуры начинается деградация люминофора и хуже показатели светоотдачи.
Зеленый нужен, да. Он вполне себе усваивается.
Гайз, по поводу выращивания зелени и прочего — любая лампа светящая белым подойдет. По большому счету количество света влияет сильнее чем качество. Если хочется идеальный свет то рецепт 4 части белого к 1 части красного 660нм. Но и без красного дело пойдет неплохо. Вопрос лишь в светоотдаче. У ЭСЛ светоотдача в среднем 80лм / ватт. Китайские светильники 80-120 лм / ватт. Брендовый свет типа lm301b под 220лм / ватт. Но они дороже и паять самому уже сложнее, нужна печь для запекания и борда.
Поэтому ставьте то что есть да побольше — все равно вырастет.
ну я ж говорю, все что светит белым можно брать. разница лишь в светоотдаче.
мало денег, бери обычные бытовые лампы белые. диодные лучше т.к. светоотдача больше.
хочешь собрать «правильный» свет и дружишь с паяльником, можно собрать самому на диодах или матрицах. 4 части белых 4000к + 1 красный 660нм(по мощности). На хабре была статья про освещение растений. диоды можно брать китайские либо фирменные типа osram | cree. можно собирать из кобов cree cxa / cxb с добавлением красного спектра.
если есть деньги и не хочешь заниматься пайкой, советую смотреть в сторону quantum boards. можно на ebay заказать или алиэкспресс.
бывают уже с добавлением красного сразу. весь вопрос в кошельке и желании.
чего не советую — брать китайские ноунейм матрицы со встроенным драйвером. особенно всякие фитоматрицы. это полное днище.
да расслабься, растет на всем если свет достаточно мощный.
вот пруф: www.youtube.com/watch?v=sfihE4IuFuU
количество света решает гораздо сильнее чем качество. понятное дело что при прочих равных спектр будет решать, но когда цена за ватт x10 а ваттов нужно много, тут уж выбор очевиден.
ну и были всякие эксперименты, что при одинаковом ФАР на белой ЭСЛ растет лучше чем даже раскрученная биспектральная лампа. а еще лучше растет при добавлении зеленого 500-600нм в проценте 20-25%.
сейчас все переползают на топовые диоды с отдачей 220лм / ватт. потому что их питают на низкий ток и охлаждать не надо кучей радиаторов. спектр там как у обычного китайского леда. все растет и никто не парится. а если денег нет, то покупай все что светит белым и все вырастет.
Прочитав статью, сразу вспоминается диалог:
— Отдам даром микроволновку: крутится, но не греет, выглядит хорошо.
— То есть курица не разогреется, но накатается вдоволь?
я вот на матрицах cxa2530 делал светильник. CRI брал 93 — очень классно светит и классно греется. Поэтому в дополнении к радиатору пришлось ставить 2 кулера. Планировал еще поставить термореле, чтобы матрицы не выгорели от случайного отключения охлаждения. Рокетсайнса нет никакого, кроме наличия дрели, сверла по металлу и паяльника. И немного прямых рук
да, я тоже поначалу удивлялся а потом понял, что это просто обида. Обида что на их язык, который функциональнее Го(это правда) так мало вакансий на рынке.
Можете рассказать, что такого предоставляет go, чего не предоставляют другие пакетные менеджеры.
причем тут пакетный менеджер, мы начинали говорить про статическую компиляцию в один файл, что не надо с собой таскать зависимости и ставить их на конечную систему.
Ну раз у вас никто не переезжает, значит, всё враки.
могу сказать зеркально и про вас. или у вас есть статистика переезда по всем компаниям?
Давайте вместе посмеемся. В чем же невероятное преимущество, и как ужасно будет выглядеть на async/await
Task<int> TrySendAsync(byte[] buffer, int offset, int size, SocketFlags flags)
{
return Task<int>.Factory.FromAsync(
_clientSocket.BeginSend, _clientSocket.EndSend,
buffer, offset, size, flags, null);
}
Task SendAsync(byte[] buffer)
{
int sent = 0;
int remaining = buffer.Length;
while (remaining > 0)
{
var partSent = await TrySendAsync(data, sent, remaining, SocketFlags.None);
sent += partSent;
remaining -= partSent;
}
}
Т.е. вот это обмазывание Task'ами с async/await вы считаете достойной альтернативой go? где ты берешь любую библиотеку и она уже будет так работать потому что это фишка языка а не нашлепка сбоку.
ну да, ну да. и в шарпе конечно нет разделяемых библиотек и проблем с версиями.
В С# полно сахара, и не встречал людей, которые бы на него жаловались. Котлин — это джава с сахаром, с какой радостью на него люди перелезают, думаю, сами видите.
у нас никто не переезжает, не слышу восторженных возгласов.
Выбранный трейдоф го мне кажется сильно заниженным.
а мне кажется вполне себе ок. лучше очевидно и просто, чем «типа просто» но порой неочевидно и с подводными камнями.
Ну так, точно также с async/await пишешь линейный код, и не паришься.
ну это еще не все языки. у нас например ни того ни другого нет. а есть питон, жава и го.
У плюсовиков вообще все грустно. В 2018 году нельзя склонировать репозиторий и нажать кнопку «restore deps and build», чтобы всё заработало с первого раза. Они обрадуются вообще чему угодно :)
да, поэтому го для меня был как манна небесная. я с ужасом представляю себе что нужно будет писать на плюсах проект. CMake, гора зависимостей и костыли при кросскомпиляции.
Причем тут придирка? Если в C# нет non-null types или там тайпклассов, я не буду говорить, что это фича, потому что мне не надо учить ничего нового. Я честно скажу: да, ребята, косяк, надеюсь в будущем исправят.
ну в каком-то смысле ограничения это хорошо. тот же пример — плюсы. мультипарадигменность, 100500 способов сделать одно и то же порождает разношерстный код. ограничения хороши для поддерживаемости проекта разными людьми. Но есть откровенно бесячие недостатки, с этим не поспоришь.
Расскажите. А то я сглупу думал, что и то и то реализация M:N многопоточности.
разница в том, что имея 4 потока в случае goroutine ты пишешь «синхронный» линейный IO код и не паришься, потому что под капотом планировщик и IO на самом деле асинхронный. В случае тасков если ты будешь так писать, то тебе быстро придет карачун и все зависнет
Один бинарь — как уже выясняли, нужная в очень специфических условиях штука, причем скорее маркетинговая, направленная на питонистов «смотрите, интерпретатор не нужон»
лол, надо плюсовикам рассказать что они на самом деле питонисты.
Ну и всё, вроде. Отсутствие фич это не фича, атеизм это не религия, а лысина — не вид прически.
всегда можно придраться к чему-то. даже в вашем любимом языке может не быть фичи, которая есть в другом языке. это конечно повод накинуть какашек и собрать плюсцов себе в карму, но на реальное положение дел это не повлияет.
Я в C# пользовался тасками примерно тогда же
вы понимаете в чем принципиальная разница между green threads и тасками?
Давайте. 80% багов, которая я когда-либо чинил, были связаны с нуллами, неявными приведениями, и комбинацией этих двух вещей. Раст обе проблемы решает радикально. Из остальных процентов 15 это бросили эксепшн, который не ожидался, и который никто не собирался ловить. Ну и 5% на все остальные случаи.
у меня совершенно другая статистика. 80% проблем это логические ошибки вроде забыли в ответ прокинуть какое-то поле. или не учли какой-то вариант входящих данных. или другой сервис отдал какую-то херню вместо json. или написали кривой запрос в бд. может быть у вас сервисы не очень сложные которые не ходят во внешние сервисы или БД?
А в данном случае если код скомпилировался, значит всё правильно.
что правильно? что память не утечет? или что вместо ожидаемого целого не придет строка? большинство проблем возникает из-за логических ошибок и никакой ЯП тут не помощник. конечно статическая типизация тут имеет свои преимущества, но чем конкретно раст в скриптах тут помогает мне непонятно.
С библиотеками — да, пока не очень густо, но для скрипта как раз-таки это не проблема, т.к. обычно его задача что-нибудь скачать посчитать, и выдать результат в консоль. Много зависимостей для этого не нужно.
скрипты скриптам рознь. нужно работать с изображениями, пдф, excel файлами и базой. что-то посчитать и вывести тут хоть что бери.
Я считаю, что главное в языке — фундамент и коммьюнити, а слава и библиотеки приходящи.
главное в языке это иметь киллер фичу, которая окажется востребованной и / или компания которая будет продвигать все это. Есть го и горутины с каналами как киллер фича. почему я должен взять раст и начать писать на нем?
Давайте оставим в стороне истории что если программа скомпилировалась то она корректна. Я каждый день чиню баги в проде, и там отнюдь не проблемы с памятью и ошибки типизации.
В бэкэнде проблема памяти на сервере не особо кого-то беспокоит, память сейчас дешевая и проще докупить плашку памяти чем тратить х2 времени разработки. Большие компании тоже не перейдут на раст ибо легаси и отсутствие библиотек. Остаются только игроделы( и то под вопросом) и энтузиасты.
А в чем тогда его киллер фича кроме жесткого компилятора в плане управления памятью, что для скрипта скорее минус чем плюс?
Порог вхождения высокий, меняющийся стандарт, отсутствие большого количества библиотек на все случаи жизни(в противовес питону например). Почему мне нужно взять раст для скрипта вместо питона например?
Я вас умоляю…
За редким исключением задача скрипта это запуститься, сделать рутину и сдохнуть, освободив память. Сколько там сожрется памяти и как быстро она освободится не играет особой роли. Тем более что скрипт может прожить в репозитории месяц и потом его выкинут за ненадобностью. Исключением здесь могут быть скрипты, лопатящие множество данных в течение продолжительного промежутка времени. Тут уже можно думать о ++ или расте.
Зеленый нужен, да. Он вполне себе усваивается.
Поэтому ставьте то что есть да побольше — все равно вырастет.
мало денег, бери обычные бытовые лампы белые. диодные лучше т.к. светоотдача больше.
хочешь собрать «правильный» свет и дружишь с паяльником, можно собрать самому на диодах или матрицах. 4 части белых 4000к + 1 красный 660нм(по мощности). На хабре была статья про освещение растений. диоды можно брать китайские либо фирменные типа osram | cree. можно собирать из кобов cree cxa / cxb с добавлением красного спектра.
если есть деньги и не хочешь заниматься пайкой, советую смотреть в сторону quantum boards. можно на ebay заказать или алиэкспресс.
бывают уже с добавлением красного сразу. весь вопрос в кошельке и желании.
чего не советую — брать китайские ноунейм матрицы со встроенным драйвером. особенно всякие фитоматрицы. это полное днище.
вот пруф: www.youtube.com/watch?v=sfihE4IuFuU
количество света решает гораздо сильнее чем качество. понятное дело что при прочих равных спектр будет решать, но когда цена за ватт x10 а ваттов нужно много, тут уж выбор очевиден.
ну и были всякие эксперименты, что при одинаковом ФАР на белой ЭСЛ растет лучше чем даже раскрученная биспектральная лампа. а еще лучше растет при добавлении зеленого 500-600нм в проценте 20-25%.
сейчас все переползают на топовые диоды с отдачей 220лм / ватт. потому что их питают на низкий ток и охлаждать не надо кучей радиаторов. спектр там как у обычного китайского леда. все растет и никто не парится. а если денег нет, то покупай все что светит белым и все вырастет.
— Отдам даром микроволновку: крутится, но не греет, выглядит хорошо.
— То есть курица не разогреется, но накатается вдоволь?
причем тут пакетный менеджер, мы начинали говорить про статическую компиляцию в один файл, что не надо с собой таскать зависимости и ставить их на конечную систему.
могу сказать зеркально и про вас. или у вас есть статистика переезда по всем компаниям?
Ок, давайте вот простой пример: приходит клиент по tcp, мы должны в рамках его сессии походить в несколько сервисов, отдать ответ и закрыть соединение. На с# я нашел такой пример:
ru.stackoverflow.com/questions/317005/sockets-clientserver-with-await-async-c-5-0
Т.е. вот это обмазывание Task'ами с async/await вы считаете достойной альтернативой go? где ты берешь любую библиотеку и она уже будет так работать потому что это фишка языка а не нашлепка сбоку.
ну да, ну да. и в шарпе конечно нет разделяемых библиотек и проблем с версиями.
у нас никто не переезжает, не слышу восторженных возгласов.
а мне кажется вполне себе ок. лучше очевидно и просто, чем «типа просто» но порой неочевидно и с подводными камнями.
ага, посмеялся.
ну это еще не все языки. у нас например ни того ни другого нет. а есть питон, жава и го.
да, поэтому го для меня был как манна небесная. я с ужасом представляю себе что нужно будет писать на плюсах проект. CMake, гора зависимостей и костыли при кросскомпиляции.
ну в каком-то смысле ограничения это хорошо. тот же пример — плюсы. мультипарадигменность, 100500 способов сделать одно и то же порождает разношерстный код. ограничения хороши для поддерживаемости проекта разными людьми. Но есть откровенно бесячие недостатки, с этим не поспоришь.
разница в том, что имея 4 потока в случае goroutine ты пишешь «синхронный» линейный IO код и не паришься, потому что под капотом планировщик и IO на самом деле асинхронный. В случае тасков если ты будешь так писать, то тебе быстро придет карачун и все зависнет
в каких?
лол, надо плюсовикам рассказать что они на самом деле питонисты.
всегда можно придраться к чему-то. даже в вашем любимом языке может не быть фичи, которая есть в другом языке. это конечно повод накинуть какашек и собрать плюсцов себе в карму, но на реальное положение дел это не повлияет.
вы понимаете в чем принципиальная разница между green threads и тасками?
шикарно.
у меня совершенно другая статистика. 80% проблем это логические ошибки вроде забыли в ответ прокинуть какое-то поле. или не учли какой-то вариант входящих данных. или другой сервис отдал какую-то херню вместо json. или написали кривой запрос в бд. может быть у вас сервисы не очень сложные которые не ходят во внешние сервисы или БД?
в теории можно писать идеальный код, который сразу компилируется и сразу работает как надо на любом языке. но почему-то никто не пишет.
что правильно? что память не утечет? или что вместо ожидаемого целого не придет строка? большинство проблем возникает из-за логических ошибок и никакой ЯП тут не помощник. конечно статическая типизация тут имеет свои преимущества, но чем конкретно раст в скриптах тут помогает мне непонятно.
скрипты скриптам рознь. нужно работать с изображениями, пдф, excel файлами и базой. что-то посчитать и вывести тут хоть что бери.
главное в языке это иметь киллер фичу, которая окажется востребованной и / или компания которая будет продвигать все это. Есть го и горутины с каналами как киллер фича. почему я должен взять раст и начать писать на нем?
Давайте оставим в стороне истории что если программа скомпилировалась то она корректна. Я каждый день чиню баги в проде, и там отнюдь не проблемы с памятью и ошибки типизации.
В бэкэнде проблема памяти на сервере не особо кого-то беспокоит, память сейчас дешевая и проще докупить плашку памяти чем тратить х2 времени разработки. Большие компании тоже не перейдут на раст ибо легаси и отсутствие библиотек. Остаются только игроделы( и то под вопросом) и энтузиасты.
Зайдёт конечно, пока будет удовлетворять время выполнения.
А в чем тогда его киллер фича кроме жесткого компилятора в плане управления памятью, что для скрипта скорее минус чем плюс?
Порог вхождения высокий, меняющийся стандарт, отсутствие большого количества библиотек на все случаи жизни(в противовес питону например). Почему мне нужно взять раст для скрипта вместо питона например?
Я вас умоляю…
За редким исключением задача скрипта это запуститься, сделать рутину и сдохнуть, освободив память. Сколько там сожрется памяти и как быстро она освободится не играет особой роли. Тем более что скрипт может прожить в репозитории месяц и потом его выкинут за ненадобностью. Исключением здесь могут быть скрипты, лопатящие множество данных в течение продолжительного промежутка времени. Тут уже можно думать о ++ или расте.