Comments 94
А в области встраиваемых систем как пишут на Си, так и продолжают писать.
я перестал верить в будущее встраиваемых систем в тот день, когда узнал, что внутри банкомата стоит обычный системный блок
Вы вспомните о них когда банкомат потребуется запульнуть в космос с питанием от батареек :)
рано или поздно батарейки подешевеют. Соблазн использовать дешевую, многократно отрабатанную архитектуру и труд массовых дешевых программистов слишком велик. Разработка под обычные системы общего пользования слишком дешева, чтобы от нее отказались.
Вы не следите за новыми веяниями, например, Internet of Things! Я бы не ставил крест на встраиваемых системах.
Скоропалительный вывод. Архитектура интернета вещей очень скоро будет унифицирована, как аппаратно (скорее всего это будет ARM Cortex или MIPSel) так и программно (linux), после чего мы вернемся к отработанной архитектуре и привычному прикладному программированию. А программирование встраиваемых решений будет нишевыми. И ниша эта будет стремительно сужаться.
А ресурсы (потребляемая мощность, размер...), необходимые для унифицированных решений, будут приемлемы? Если каждому болтику потребуется по полватта на поддержку линукса, то хозяин разорится на счетах за электричество.
Вы правы, архитектура будет унифицироваться, только вот linux встает только на Cortex-A — серии, а такое устройство от батарейки(сравнимой с пальчиковыми) не запитаешь, а вот Cortex-M — серии запитаешь, да вот беда туда linux(не считая отдельных сборок, которые имеют сереьзные изменения) не влезет. В целом я считаю что индустрия будет расти, хотя я полностью поддерживаю автора данной статьи и помимо совершенствования себе в программировании встраиваемых систем, учу веб-программирование.
Поверьте, писать ПО на C под Linux несравнимо проще, чем писать полноразмерную ОСРВ для утрамбовки ее в 4k ROM + 8k RAM с безумным ASM. MIPSEL вполне себе вариант туда, где надо запитать.
Кроме того, количество систем, где надо запускать в небо холодильник, который проработает 10 лет от одной LR батарейки — сильно преувеличено, поверьте. Многие системы после минимального тюнинга прекрасно будут жить с мощными и горячими cortex-A, устройства на Android тому яркий пример
Кроме того, количество систем, где надо запускать в небо холодильник, который проработает 10 лет от одной LR батарейки — сильно преувеличено, поверьте. Многие системы после минимального тюнинга прекрасно будут жить с мощными и горячими cortex-A, устройства на Android тому яркий пример
А внутри самолёта тоже будет стоять обычный системный блок?
Вы не поверите, но они там стоят. Ну, не обычные конечно, в авиакосмическом исполнении, но архитектурно это всё те же писюки во многих случаях. Не знаю как дело обстоит сейчас, но МКС в первые годы после запуска, например, управлял писюк на базе i386 (больше производительности там просто не надо, а тех.процесс в космосе имеет обратное значение — чем толще, тем лучше), а в качестве терминалов используются массовые ноутбуки повышенной надежности.
А сколько сотен микропроцессоров раскидано по всему самолёту? И каждому нужна своя прошивка.
Где-то на Хабре видел статью где утверждалось, что тоньше — защищеннее.
На танках серии Т-90 кажется 8086 стоят.
На современных истребителях (российских Су и Як) стоит блочок с i586 (pentium-1), исполнения компании AMD. +SRAM для данных.
я тоже так думал, но оказывается нам в компанию приняли нового человека и он интерфейс GUI встраиваемой системы сделал на html/css/javascript — руки бы ему поотрывать.
Теперь GUI нашей встраиваемой системы ужасно тормозит и никто не знает как все это починить.
Предыдущая модель системы хотя бы использовала QT — и все работало шустро.
Зато теперь мы используем передовые технологии.
Теперь GUI нашей встраиваемой системы ужасно тормозит и никто не знает как все это починить.
Предыдущая модель системы хотя бы использовала QT — и все работало шустро.
Зато теперь мы используем передовые технологии.
а что такого тормозного в html css js? Вот говорят интернет весь на ентой технологии.
WWW — еще не весь интернет.
И интернет сам еще не весь на своих технологиях.) За QT надо платить не QT-ёво.
Человек судит о системе по ее интерфейсу. Это довольно пользовательский подход винить технологию интерфейса. Че за система, че за QT, че там все не понимают как исправить и зачем исправлять тем кто не понимает. Система торомозит — виновата верстка.) Разбираться надо))) Винить очень опасно технологию. Она не плохая и не хорошая. Она просто вот какая есть.
Да, конечно, от десктопных приложений отклик быстрее и главное не моргает при перерисовке. Но это все разговор без предмета разговора. там миллион всяких причин, взять ту же скорость исправления багов при клиент серверной схеме через браузер и через клиент-приложение.
Да, я тоже не люблю многие вещи на html, но вся эта не любовь в определенных случаях съедается просто офигенно удобными вариантами решений каких либо задач.
Я не ругаю автора, просто вот так вот… еще плюсуют пост. )QT — класс. HTML — плохо. Аналогично кросовки — хорошо, сандали — плохо. Да нет предмета разговора)
Человек судит о системе по ее интерфейсу. Это довольно пользовательский подход винить технологию интерфейса. Че за система, че за QT, че там все не понимают как исправить и зачем исправлять тем кто не понимает. Система торомозит — виновата верстка.) Разбираться надо))) Винить очень опасно технологию. Она не плохая и не хорошая. Она просто вот какая есть.
Да, конечно, от десктопных приложений отклик быстрее и главное не моргает при перерисовке. Но это все разговор без предмета разговора. там миллион всяких причин, взять ту же скорость исправления багов при клиент серверной схеме через браузер и через клиент-приложение.
Да, я тоже не люблю многие вещи на html, но вся эта не любовь в определенных случаях съедается просто офигенно удобными вариантами решений каких либо задач.
Я не ругаю автора, просто вот так вот… еще плюсуют пост. )QT — класс. HTML — плохо. Аналогично кросовки — хорошо, сандали — плохо. Да нет предмета разговора)
Спасибо, годный перевод. А мне очень нравится текущее положение вещей. Из-за большого выбора и динамики развития, работа наша очень интересная!
Чувак просто античный. Привык, что ничего не меняется.
У меня вот депрессия начинается, если я за неделю не изучил ни одной новой технологии или не создал ни одной новой крутой фишки.
У меня вот депрессия начинается, если я за неделю не изучил ни одной новой технологии или не создал ни одной новой крутой фишки.
getsmarter.ru/
Здесь тоже говорится про каток. Интересно, авторы случайно выбрали одинаковую ассоциацию?
Здесь тоже говорится про каток. Интересно, авторы случайно выбрали одинаковую ассоциацию?
На рисунке из статьи Ярослав Кеслер, Цивилизационные события, как основа хронологии ( edgeways.ru.mastertest.ru/public/index.php?doc=49 )
показана зависимость между изобретением и масштабным использованием изобретения.
Похоже, после изобретения искусственного интеллекта изобретения побегут впереди мыслей о них.
показана зависимость между изобретением и масштабным использованием изобретения.
Похоже, после изобретения искусственного интеллекта изобретения побегут впереди мыслей о них.
Если бы подобный график нарисовал Ньютон, то линия тоже воткнулась бы в ноль где-нибудь в 1680 году. Человек так устроен, что видит фиксированное число главных событий на 1 порядок времени (от 10 до 100 лет в прошлое, от 100 до 1000...) Остальное — свойства геометрической прогрессии.
Кстати, а когда в СССР всем начали преподавать интегралы с формулой Ньютона-Лейбница?
Вы график-то хоть прочитали? Или мы по вашему живем в 7500+ году?
Есть и такой вариант — 7521 от сотворения мира. Но я лично считаю, что новая эра ещё не началась.
Новая эра начнётся, когда этот график пересечёт ось абсцисс. Правда, это возможно только после изобретения машины времени (ну или хотя бы предсказания будущего), когда все, все новые изобретения станут использоваться всё раньше и раньше — сперва за недели, затем за месяцы, за годы, за десятилетия до момента их действительного изобретения.
До некоторой степени пересечение оси абсцисс происходит ужé сейчас и известно достаточно широко под названиембета-тестирования, позволяющего использовать ту или иную технологию (библиотеку, программу, сайт) за несколько месяцев (а иногда и за несколько лет) до их окончательного оформления и появления на свет Божий.
До некоторой степени пересечение оси абсцисс происходит ужé сейчас и известно достаточно широко под названием
Я не знаю, по какому летоисчислению Вы живете. На графике есть точка «Интернет», которая соответствует 1991г. новой эры в солнечных годах (0 тоже обозначен на графике). Константу смещения подберите, пожалуйста, сами.
Технологическая сингулярность, ага… Странно, что никто тут её не упомянул, хотя вон график даже есть и прогноз по нему соответствующий.
У нас сейчас ядерный век (или космический, как кому нравится), а почему-то по ссылке по теме все очень скудно, нет открытия радиоактивности и квантовых исследований, космических станций, и ошибки есть: квантовые генераторы первые появились еще в середине прошлого века, почему лазер отнесен к 2000?
Не верьте в эти сказки. Качественный разработчик (в нашем случае) сможет очень долгое время работать и приносить пользу, используя все те же навыки. Иногда почитывая хабр и прочие ресурсы — он очень плавно меняется вместе с миром вокруг него.
Наглядный пример точки зрения автора?
UFO just landed and posted this here
Указатели были убиты автоматическою сборкою мусора. Теперь никто не выделяет память и не оперирует указателем на него, кроме авторов тех движков, которые реализуют языки более высокого уровня — этим авторам, беднягам, приходится до сих пор сочинять на Си да на Си++, но этот свой крест они несут с честью, и тем искуплено всё остальное человечество (точнее, «программистство», но такого слóва до сих пор нет на свете — и, может быть, слава Богу).
UFO just landed and posted this here
Ну да, как Пауль Фейерабенд писал в своем «Against Method», что наука нередко развивается посредством отрицания старых методов, и для полноценного развития науки необходимо также контриндуктивное направление.
Забавно, что автор воспринимает «каток» как какую-то нечеловеческую стихию. А каток толкают такие же люди, как и автор. Так что гнать все быстрее и быстрее просто чтобы гнать, никто не будет.
Будут. Потому что если остановишься, другие догонят и затопчут. Или просто обгонят навсегда.
Да, Спольски это называл «огнём прикрытия». Создание новых технологий, чтобы конкурентам оставалось только догонять.
Но каждый отдельный человек может бежать только с некоторой максимальной скоростью. И весь каток в целом не будет сильно эту скорость превышать, как мне кажется. Далеко не все задачи можно решать увеличением количества исполнителей («мифический человеко-месяц»).
Но в целом, причины этого заблуждения понятны. Любое достаточно крупное образование воспринимается как нечто безличное — будь то «государство», «прогресс» или «корпорация».
Но в целом, причины этого заблуждения понятны. Любое достаточно крупное образование воспринимается как нечто безличное — будь то «государство», «прогресс» или «корпорация».
Будет, потому что скорость движения катка складывается из усилий всех людей, которые имеют отношение к программированию и ИТ вообще, а количество таких людей увеличивается. Наряду с множеством профессиональных программистов ИТ также «растворяются» практически во всех отраслях, у которых есть будущее, включая разработку железа, дизайн, биотех, а в перспективе еще и нанотех. Когда количество занятых в ИТ достигнет насыщения — к людям начнут присоединяться ИИ-разработчики, не говоря уже об увеличении интеллектуальной продуктивности самих людей посредством все более тесной интеграции с технологиями. Так что даже то, что наблюдается сегодня, это еще цветочки:). Уже сейчас констатировать необходимость постоянного обучения «чему-нибудь» недостаточно — нужно учиться оптимизировать свои способности к обучению. Грубо говоря, затачивать топор (а затем создавать что-то еще более эффективное) вместо махания тупой железякой с большей интенсивностью.
«Now, here, you see, it takes all the running you can do,
to keep in the same place. If you want to get somewhere
else, you must run at least twice as fast as that!»
Написано почти 150 лет назад…
Тоже самое и в игровой индустрии со стороны арт-направления. Еще года три-четыре и меня спишут в утиль. Пока знания еще актуальны, но в общем и целом… придется снова учиться. И вряд ли это получиться хорошо, слишком уж много меняющихся каждый год пакетов. Да и сил нет постоянно выдерживать эту гонку. Даже находясь на коне ты все равно с него сваливаешься либо тебя валят.
Одно радует. Развитие ретро-направлений. Там моих знаний хватит. Остается только молиться чтобы в этом мире был хотя бы миллион ретро людей. В этом случае на корку хлеба наскрести удастся. Возможно. На худой конец на сушку. Одну.
Одно радует. Развитие ретро-направлений. Там моих знаний хватит. Остается только молиться чтобы в этом мире был хотя бы миллион ретро людей. В этом случае на корку хлеба наскрести удастся. Возможно. На худой конец на сушку. Одну.
Вам следовало бы дать здесь гиперссылку на блогозапись «Фактура убила текстуру?» и тем достигнуть у читателей существенно бóльшего (а главное — много более подробного) понимания того процесса, который Вы здесь имеете в виду.
(Но я вполне понимаю, что скромность остановила Вас — так что вместо того я сам решил поставить здесь эту гиперссылку, и поставил.)
(Но я вполне понимаю, что скромность остановила Вас — так что вместо того я сам решил поставить здесь эту гиперссылку, и поставил.)
Думаю, что сам процесс «гонки вооружения», как в случае публикации топик-стартера (который написал большой и существенный текст) нуждается в большей проработке с моей стороны, по части арт и дизайн направлений. Их у меня пока нет. В упомянутой заметке «Фактура убила текстуру?» гораздо больше размышлений и предположений, нежели конкретики.
Этому можно было бы посвятить целую историко-аналитическую публикацию. Но рук просто не хватает. Разрываюсь между событиями сегодняшнего дня, истории и собственно туториалов которые по результатам голосования склоняются более к практическим навыкам, которые могут быть применены на деле.
В любом случае спасибо. У меня не было даже мысли снабдить свой ответ этой ссылкой. Если она кому-нибудь поможет — буду только рад. Если с кем-то мы сойдемся во мнениях — найдутся единомышленники, а если с кем-то окажемся несогласными, можем подискутировать. Правда, увы, только завтра.
Еще раз спасибо.
Этому можно было бы посвятить целую историко-аналитическую публикацию. Но рук просто не хватает. Разрываюсь между событиями сегодняшнего дня, истории и собственно туториалов которые по результатам голосования склоняются более к практическим навыкам, которые могут быть применены на деле.
В любом случае спасибо. У меня не было даже мысли снабдить свой ответ этой ссылкой. Если она кому-нибудь поможет — буду только рад. Если с кем-то мы сойдемся во мнениях — найдутся единомышленники, а если с кем-то окажемся несогласными, можем подискутировать. Правда, увы, только завтра.
Еще раз спасибо.
Есть вариант встать не место молодых (если мозги не заржавели) и попробовать начать с нуля. У молодых же получается некоторое время быть на гребне, до того как оказываются под катком. У многих. Наверно должен быть способ имитировать нечто подобное, вновь и вновь?..
во, в тему — тут же ниже: habrahabr.ru/post/182810/#comment_6357120
Не думаю. Но не думаю — только для себя. Уже выбрал свой путь осознанно. Мое движение — будет движением назад. Точно также как это делают сотни других разработчиков делая ставку на оригинальность, гейм-плей и следование старым традициям, когда игры делались ради игр, ради гейм-плея.
Пусть технологи идут дальше. Эффекты, шейдеры технологические новинки, и другие прибамбасы я буду рассматривать теперь как потребитель, а не как участник. Не думаю, что нужно пытаться за кем-то угнаться. Нужно просто найти свое место. Нашел его я или нет узнаем через десяток лет. По результатам работы.
Пусть технологи идут дальше. Эффекты, шейдеры технологические новинки, и другие прибамбасы я буду рассматривать теперь как потребитель, а не как участник. Не думаю, что нужно пытаться за кем-то угнаться. Нужно просто найти свое место. Нашел его я или нет узнаем через десяток лет. По результатам работы.
Всё идёт к тому, что, выбрав некоторую задачу, программист вынужден будет учить конкретный пакет технологий специально под неё. А как только задача выполнена, очищать мозговую оперативку — в дальнейшем выученное не понадобится, под новую задачу придётся учить с нуля новые средства и пакеты.
Т.е. в IT-отрасли будут цениться не конкретные знания (которые будут устаревать практически мгновенно, в считанные недели), а способность как можно быстрее загрузить в память произвольный набор знаний и по завершении работы столь же быстро их забыть.
Т.е. в IT-отрасли будут цениться не конкретные знания (которые будут устаревать практически мгновенно, в считанные недели), а способность как можно быстрее загрузить в память произвольный набор знаний и по завершении работы столь же быстро их забыть.
способность как можно быстрее загрузить в память произвольный набор знаний и по завершении работы столь же быстро их забыть
А не этот ли навык тренирует наше высшее образование? ;)
А не этот ли навык тренирует наше высшее образование? ;)
Если добавить, что «работой» может быть создание следующей ступеньки технологии, которую будут «загружать в память» уже другие (а может быть, и сам автор — но в другой раз), то всё это очень похоже на правду. А цениться будет наличие «меташаблонов», на которые можно легко поместить новые знания.
У меня уже все происходит практически таким образом. Но забывать все после выполнения задачи все же не стоит, да и не удается. К задачам зачастую приходится возвращаться.
Я думаю, что в области электронных компонентов всё меняется ещё быстрее. Голова идёт кругом от того с какой скоростью, например, появляются новые семейства микроконтроллеров, микропроцессоров, DSP, памяти, СВЧ микросхем… Если на год — другой отойти от дел, вернёшься как в новый мир!
Такой «каток» — он во всех передовых (читай — не сильно отстающих) областях науки и техники. Не выпустил статью/отчет о работах — завтра прочитаешь об аналогичном как о прорыве. Поддерживать себя в ритме — это, на мой взгляд, основная цель разработчика (инженера, конструктора, etc.). Не обязательно досконально разбираться во всех «модных трендах», но быть в курсе — «must have».
Мне кажется, что всё-таки существуют области IT, где каток движется не так быстро. Системное программирование, к примеру. Ядру Linux уже 22 года, Git, Hadoop, DTrace — 8 лет. Никто их не стремится переписывать в срочном порядке. Бывает, что меняются API, но не раз в неделю/месяц.
UFO just landed and posted this here
Годная статья, но хочу добавить: учить конкретный стек языков и технологий — вообще бесперспективное занятие. В другой задаче они будут другие. Учить надо базисные вещи, на уровне физики и математики 7 класса школы: почему память быстрее диска, почему сетевое соединение не надёжно, почему сложные выборки медленнее простых, почему целые числа быстрее дробных, почему несколько мелких файлов лучше одного большого, почему память сегментирована, почему два слабых компьютера выгоднее одного мощного, и так далее.
Владея этими базовыми пониманиями, человек никогда не будет творить %уйню типа SQL-запросов с JOIN-ами, XML-шаблонизаторов, баз данных на миллионы строк и монолитных веб-приложений :)
Владея этими базовыми пониманиями, человек никогда не будет творить %уйню типа SQL-запросов с JOIN-ами, XML-шаблонизаторов, баз данных на миллионы строк и монолитных веб-приложений :)
А почему «два слабых компьютера выгоднее одного мощного»?
Потому что, в контексте отказоустойчивости, мини-кластер из двух компьютеров экономически выгоднее одного (даже более мощного), так как обеспечивает работу приложения (а значит непрерывность бизнес-процессов) при выходе из строя например блока питания или процессора одного из них.
Потому что, изначально дублируя каждый компонент приложения в двойном экземпляре, гораздо легче потом (при росте нагрузки) сделать 3-ий, 4-ый узел и так далее. Не заложив этого в фундаменте приложения, потом будет труднее.
Потому что существуют, например, физические пределы скорости жестких дисков, и распараллелить задачу требующую дисковую активность — на два (на 3, 4, 5...) физических компьютера — означает выполнить её быстрее.
Достаточно?
Потому что, изначально дублируя каждый компонент приложения в двойном экземпляре, гораздо легче потом (при росте нагрузки) сделать 3-ий, 4-ый узел и так далее. Не заложив этого в фундаменте приложения, потом будет труднее.
Потому что существуют, например, физические пределы скорости жестких дисков, и распараллелить задачу требующую дисковую активность — на два (на 3, 4, 5...) физических компьютера — означает выполнить её быстрее.
Достаточно?
Вопрос позвольте-с. Почему человек никогда не будет творить SQL-запросы с JOIN-ами?
Ну я надеюсь, по крайней мере, что не будет :)
Потому что JOIN — это операция объединения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом объединять данные, когда можно их объединить один раз где-то на стороне, и хранить уже объединённые? Процессорное время стоит денег, особенно если ваше приложение работает в «облаке» на десятках компьютеров с оплатой за потребление ресурсов.
Погуглите по фразе «денормализация БД».
Потому что JOIN — это операция объединения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом объединять данные, когда можно их объединить один раз где-то на стороне, и хранить уже объединённые? Процессорное время стоит денег, особенно если ваше приложение работает в «облаке» на десятках компьютеров с оплатой за потребление ресурсов.
Погуглите по фразе «денормализация БД».
GROUP BY — это операция группировки данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом группировать данные, когда можно их сгруппировать один раз где-то на стороне, и хранить уже сгруппированные?
ORDER BY — это операция сортировки данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом сортировать данные, когда можно их отсортировать один раз где-то на стороне, и хранить уже отсортированные?
SELECT — это операция чтения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом считывать данные, когда можно их прочитать один раз где-то на стороне, и хранить уже прочитанные?
Погуглите по фразе «right tool for the job».
ORDER BY — это операция сортировки данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом сортировать данные, когда можно их отсортировать один раз где-то на стороне, и хранить уже отсортированные?
SELECT — это операция чтения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом считывать данные, когда можно их прочитать один раз где-то на стороне, и хранить уже прочитанные?
Погуглите по фразе «right tool for the job».
О-о-о… Далеко пойдёте с таким подходом. Может быть, у вас приложение каждый раз заново инициализируется при каждом обращении пользователя? Этакий PHP-стайл мышления, раз мысль об оптимизации повторяющися действий кажется вам странной.
Топикстартер вроде как про развитие писал, а Вы в каменном веке застряли.
Топикстартер вроде как про развитие писал, а Вы в каменном веке застряли.
мысль об оптимизации повторяющися действий кажется вам странной
мне кажется странной такая мысль:
человек никогда не будет творить *** типа SQL-запросов с JOIN-ами
Да я вижу, у вас типично «скриптовый» образ мышления, это когда пишут приложения на PHP/Perl/etc — как скрипты, которые при каждом запросе пользователя считываются с диска, интерпретируются, лезут в базу с одними и теми же запросами и т.д.
Понимание того, что так делать не надо, приходит обычно когда начинаешь обрабатывать более 1к пользователей в секунду, а база проекта начинает измеряться сотнями миллионов объектов и расползаться по 10-20 серверам.
Посмотрел бы я на вас, если бы вы решили приджойнить к чему-нибудь табличку users с 10 миллионами пользователей, ещё с GROUP BY и ORDER BY впридачу, ага :)
Но большинство «разработчиков» до жопы ленивы, всю жизнь клали болт на своё развитие и самообучения, никогда даже рядом с такими проектами не стояли, предпочитают вместо профессионального роста дрочить на карму на хабре, и до седых волос будут считать что JOIN-ы и вся вышеперечисленная %уйня — это нормально.
Быть среди таких или думать своей башкой — вам решать.
Понимание того, что так делать не надо, приходит обычно когда начинаешь обрабатывать более 1к пользователей в секунду, а база проекта начинает измеряться сотнями миллионов объектов и расползаться по 10-20 серверам.
Посмотрел бы я на вас, если бы вы решили приджойнить к чему-нибудь табличку users с 10 миллионами пользователей, ещё с GROUP BY и ORDER BY впридачу, ага :)
Но большинство «разработчиков» до жопы ленивы, всю жизнь клали болт на своё развитие и самообучения, никогда даже рядом с такими проектами не стояли, предпочитают вместо профессионального роста дрочить на карму на хабре, и до седых волос будут считать что JOIN-ы и вся вышеперечисленная %уйня — это нормально.
Быть среди таких или думать своей башкой — вам решать.
Да я вижу, у вас типично «скриптовый» образ мышления
Где хрустальный шар раздобыли? Сайт цыганам делали?
Понимание того, что так делать не надо, приходит обычно когда начинаешь обрабатывать более 1к пользователей в секунду, а база проекта начинает измеряться сотнями миллионов объектов и расползаться по 10-20 серверам.
Конечно, у Вас длиннее. Я гляжу, тут на Хабре, каждый второй хайлоад держит и чем больше минусов у человека, тем серьезнее хайлоад. Почему бы Вам не выложить ссылку в комментарии или профиль, чтобы можно было оценить Ваш реальный опыт, которым Вы бравируете? Иначе выходит, что "… ну я читал в интернете...".
Посмотрел бы я на вас, если бы вы решили приджойнить к чему-нибудь табличку users с 10 миллионами пользователей, ещё с GROUP BY и ORDER BY впридачу, ага :)
Джоин тут может быть эффективен или не эффективен. Скорее не эффективен. Но в случае с меньшим колическтвом записей, он может быть эффективен. Значит ли это что джоин — плохо? — Нет. Это значит надо думать и выбирать инструменты под задачу. И думать над архитектурой. Но говорить, что джоин — всегда плохо, когда он оказался не эффективен в одной ситуации — очень глупое обобщение.
Но большинство «разработчиков» до жопы ленивы, всю жизнь клали болт на своё развитие и самообучения, никогда даже рядом с такими проектами не стояли,
Это про меня. Как точно подмечено! Вы, само собой, не из их числа.
предпочитают вместо профессионального роста дрочить на карму на хабре
А если я скажу, что карма — показатель Вашего профессионализма? Ведь легко говорить о «профессиональном росте» когда его нельзя измерить. А если Вам предложить шкалу его измерения? Вы сможете пережить, тот факт, что Ваш «профессионализм» может иметь отрицательное значение? Уверен, что правильность такой шкалы будет зависеть от того, в плюсе ли Вы или нет.
до седых волос будут считать что JOIN-ы и вся вышеперечисленная %уйня — это нормально.
А есть дураки, которые считают, что ключ на 16 — это нормально. Нет, Вы только представьте! Они-то, убогие, не в курсе, что единственно верный ключ — на 24.
Быть среди таких или думать своей башкой — вам решать.
Ок.
Вы профессиональный тролль или просто страдаете радикализмом?
«почему несколько мелких файлов лучше одного большого» вот это спорный момент. Все зависит от контекста.
UFO just landed and posted this here
Sign up to leave a comment.
Каток никого не ждет