Порядок странный из-за того что часто не весь состав едет в один и тот-же пункт назначения. Часто к составу цепляют вагоны по пути, часто их отцепляют..
Изобретатель Джеймс Фаулер создал локомотивы с конденсацией пара — они собирали отработанный пар обратно в резервуар.
Наверное там скорее речь про безтопочные паровозы, в них пар и перегретую воду закачивали в котел на стационарных станциях подзарядки, после чего они довольно далеко могли передвигаться. При отсутствии электрической тяги это был более-менее приемлемый вариант для туннелей и вообще мест где нежелателен открытый огонь.
Видимо повлияла попытка "скрещивания" на начальном этапе приставки и БК, что в общем-то было здравой идеей для того времени, но от приставок ошибочно решили позаимствовать схему распространения ПО, когда производитель приставок полностью контролирует весь софт для них. Но на рынке БК это уже не работало, их и покупали то во многом из-за свободы и количества доступного софта.
Потому что большинство работает в командах на проектах, где все эти оптимизации либо кто-то уже давно делал, либо есть отдельные девопсы, которые всем этим занимаются. Обычный рядовой разраб редко во все это погружается.
Это, видимо, отсылка к его словам о том что он финн, а финны ненавидят русских поэтому дискриминировать их для него нормально. Не дословно, но по смыслу так..
Эхх не удержался, прощай карма, щас ее уничтожат линуксофилы..
Все ФАР вроде так и работают, на каждый излучатель подается сигнал со своей фазой, рассчитанной так что-бы суммарный сигнал от всех излучателей образовывал стоячую волну с пиками в нужных местах. Довольно интересная тема, может на выходных пороюсь в истории и найду ссылку, сейчас на это времени нет.
У меня кронштейн под маленькую солнечную панель для гирлянды, напечатанный на ПЛА уже четвертый год на улице живет и все с ним в порядке. Условия самые жесткие, солнце, дождь, снег, мороз, держится пока. Форму не потерял, не пожух, выглядит как только что напечатанный, разве что чуть подвыгорел. Так что нестойкость этого пластика сильно преувеличенна.
Написать несложно, только результаты вам потом надо из рекрдсета вытащить, запихнуть в ДТО, привести все типы, и т.д. и т.п. Это не сложно, конечно, но зачем писать лишний код?
С другой стороны если у вас проект на JPA, то вам никто не помешает в нужных местах использовать нативные запросы на этом же JPA, для особых случаев, либо вовсе использовать JDBC если без него никак.
Для простых применений, которых в практике большинство, ОРМ просто позволяет экономить время и довольно удобен. Если говорить о JPA, то ты просто из коробки получаешь целую кучу функционала без написания лишнего бойлеркода. Задал источники данных, описал сущности, репозитории и ты уже можешь делать 80% всего того что тебе потребуется делать на БД. Это реально удобно и реально экономит массу времени.
Ну а если нужно что-то особенно то всегда можно прикрутить нативный запрос или JDBC, или тот-же Жук, никто не запрещает использовать все это в одно проекте.
Как по мне самый удобный и правильный выбор - это JPA + нативные запросы для особо сложных случаев, и JDBC там, где надо прямо что-то совсем специфичное, где нужен полный контроль и максимум производительности.
Примерно на половине текста уже хотел идти в комменты и писать какое дерьмо эти метрики.. но потом все-же дочитал и увидел что автор сам это признал.
Человек много проводит времени возле кофе-машины, ну так может быть ему лучше думается так.. Мы ведь не у станка работаем, нам часто надо подумать и бывает что думается лучше всего подальше от компьютера, что-бы ничего не отвлекало.
Либо это хороший способ неформально пообщаться с коллегами и из этого тоже может быть много пользы для дела, можно что-то новое узнать, какие-то непонятки-нестыковки устранить, просто лучше узнать человека и с ним будет приятнее и эффективнее работать..
В общем не получается все эти примитивные метрики приметить к живым людям, занимающимся сложной деятельностью.
Порядок странный из-за того что часто не весь состав едет в один и тот-же пункт назначения. Часто к составу цепляют вагоны по пути, часто их отцепляют..
Об этом не слышал, интересное дополнение, спасибо
Наверное там скорее речь про безтопочные паровозы, в них пар и перегретую воду закачивали в котел на стационарных станциях подзарядки, после чего они довольно далеко могли передвигаться. При отсутствии электрической тяги это был более-менее приемлемый вариант для туннелей и вообще мест где нежелателен открытый огонь.
Чувствуется эффективный менеджмент :)
Видимо повлияла попытка "скрещивания" на начальном этапе приставки и БК, что в общем-то было здравой идеей для того времени, но от приставок ошибочно решили позаимствовать схему распространения ПО, когда производитель приставок полностью контролирует весь софт для них. Но на рынке БК это уже не работало, их и покупали то во многом из-за свободы и количества доступного софта.
Да уж, в и без того непростой конкурентной ситуации умудриться поссориться с потенциальными разработчиками - это серьезная заявка на успех.
Вот, порылся в истории просмотров и нашел..
https://www.youtube.com/watch?v=z4uxC7ISd-c
Потому что большинство работает в командах на проектах, где все эти оптимизации либо кто-то уже давно делал, либо есть отдельные девопсы, которые всем этим занимаются. Обычный рядовой разраб редко во все это погружается.
Это, видимо, отсылка к его словам о том что он финн, а финны ненавидят русских поэтому дискриминировать их для него нормально. Не дословно, но по смыслу так..
Эхх не удержался, прощай карма, щас ее уничтожат линуксофилы..
Вроде история со сложением строк уже давно не актуальна, компилятор достаточно умён чтобы заменить ее на билдер "под капотом".
Все ФАР вроде так и работают, на каждый излучатель подается сигнал со своей фазой, рассчитанной так что-бы суммарный сигнал от всех излучателей образовывал стоячую волну с пиками в нужных местах. Довольно интересная тема, может на выходных пороюсь в истории и найду ссылку, сейчас на это времени нет.
вот выше, ПЛА, круглосуточно на солнце, уже много лет, выглядит так-же как когда был напечатан
Не, там именно ФАР, для сканирования пространства, надо в истории покопаться, поискать
В сети видел как делали аналог ФАР для ультразвука, для сканирования пространства, и это работало.
У меня кронштейн под маленькую солнечную панель для гирлянды, напечатанный на ПЛА уже четвертый год на улице живет и все с ним в порядке. Условия самые жесткие, солнце, дождь, снег, мороз, держится пока. Форму не потерял, не пожух, выглядит как только что напечатанный, разве что чуть подвыгорел. Так что нестойкость этого пластика сильно преувеличенна.
Написать несложно, только результаты вам потом надо из рекрдсета вытащить, запихнуть в ДТО, привести все типы, и т.д. и т.п. Это не сложно, конечно, но зачем писать лишний код?
С другой стороны если у вас проект на JPA, то вам никто не помешает в нужных местах использовать нативные запросы на этом же JPA, для особых случаев, либо вовсе использовать JDBC если без него никак.
Для простых применений, которых в практике большинство, ОРМ просто позволяет экономить время и довольно удобен. Если говорить о JPA, то ты просто из коробки получаешь целую кучу функционала без написания лишнего бойлеркода. Задал источники данных, описал сущности, репозитории и ты уже можешь делать 80% всего того что тебе потребуется делать на БД. Это реально удобно и реально экономит массу времени.
Ну а если нужно что-то особенно то всегда можно прикрутить нативный запрос или JDBC, или тот-же Жук, никто не запрещает использовать все это в одно проекте.
Как по мне самый удобный и правильный выбор - это JPA + нативные запросы для особо сложных случаев, и JDBC там, где надо прямо что-то совсем специфичное, где нужен полный контроль и максимум производительности.
Во многих сферах деятельности так все и работает, нравится нам это или нет..
Решается просто общим счетчиком для всех смен. Общий простой за месяц становится общей проблемой всех ремонтников.
Примерно на половине текста уже хотел идти в комменты и писать какое дерьмо эти метрики.. но потом все-же дочитал и увидел что автор сам это признал.
Человек много проводит времени возле кофе-машины, ну так может быть ему лучше думается так.. Мы ведь не у станка работаем, нам часто надо подумать и бывает что думается лучше всего подальше от компьютера, что-бы ничего не отвлекало.
Либо это хороший способ неформально пообщаться с коллегами и из этого тоже может быть много пользы для дела, можно что-то новое узнать, какие-то непонятки-нестыковки устранить, просто лучше узнать человека и с ним будет приятнее и эффективнее работать..
В общем не получается все эти примитивные метрики приметить к живым людям, занимающимся сложной деятельностью.