логичное следствие того, что 95% населения — идиоты
логичное следствие — это нормальное распределение компетенций восприятия мира в мозгу конкретного индивида.
На примере: баба Маша лучше всех на деревне печет хлеб. Для нее все остальные, которые думают, что умеют печь хлеб — идиоты. Как правило подобная компетенция обществом признается и уважается.
Ложные компетенции, на примере противопоставления большинству. В сельский ДК приехал районный театр. Все пошли на спектакль, а дядя Ваня пошел на рыбалку, считая остальных стадом баранов, которые все равно ничего не понимают в искусстве, а пошли только из-за халявных билетов, что раздал председатель колхоза. Возможно, дядя Ваня и лучший на деревне рыбак, но явно не знаток искусства. Как правило подобные «компетенции» (в области искусства дяди Вани) обществом игнорируются, до тех пор пока индивид не начнет требовать их признания. Результатом таких попыток может стать жесткое противостояние общества и индивида.
Давно подыскиваю интересную книжку для сына, что-бы сразу можно было «пощупать», что это такое, а не тривиальный «Hello, world!». Особенно радует, что такая книга появилась для C++
Я не специалист по технологиям дешевого термоядерного синтеза, возможно там все проще, но при попытке реализовать любую идею в жизнь, вы столкнетесь, как бы это сказать попроще — с реальностью (ну не возможно все предусмотреть на бумаге). И вот кто-то вбухивает сотни миллионов в этот проект, ученые проводят многолетние исследования, доработки и пр… И тут появляетесь вы со своим патентом. Угадайте, кто Вы?
Мега-супер-пупер удобно когда текст читаешь и не перекрываешь пальцем экран, но на большее сенсорная клавиатура не годиться — в экран тыкать удобнее. Зимой нормуль все, но в перчатках сенсор не работает, но мне это и не нужно — я как-то не любитель долго по морозу гулять, проще снять
Так я и не говорю что это не нужно. Я всего лишь обозначил то, что навыки владения клавиатурой вообще никак не коррелируют с качеством и скоростью разработки. Просто зацепило "(а я много пишу кода)"
Минусов, я думаю, вы не нахватаете, потому что во многом вы правы. Но баланс между скоростью (много бесполезного не поддерживаемого кода) и качеством (меньше кода, легко разобраться и поддерживать) вы найдете только с опытом. Бесполезно прочитав «умную» книжку тратить уйму времени над обмыванием «идеальной» архитектуры. Все ваши измышления уйдут в топку, как только вы столкнетесь с реальностью. Анализируйте ваши предыдущие проекты, делайте выводы, оптимизируйте процесс разработки. Ну а тренинги по оптимизации клацания по клаве вещь во многом полезная, но реального профита для разработки не дает, разве что произвести впечатление на коллег или начальника.
Вообще-то пост не о этом. Но ради эксперимента попробовал — 5 минут на С++. Безумно много, согласен. Но это 100 строк за рабочий день. Разуметься тыкать карандашом по клаве по 8 часов подряд у меня не получиться, но если случиться несчастье — то именно эта та практика, которую имеет смысл практиковать. И слепые умудряются кодить
Когда я был «маленький» я тоже много говнокодил и активно изучал mouse-less. Я смеялся над умными книгами, где говорилось, что в среднем программист пишет 10 строк кода в день. Ха-ха! же несколько тысяч мог накодить! Когда я стал «старым» и медлительным, я анализировал проекты своей молодости которые ушли в продакшн и, с учетом отладки, тестирования, исправления багов и пр. — картина не радужная. В итоге получается, конечно не 10 строк в день, но и завершенными проектами эти поделки назвать сложно. А чтобы их завершить нужно… взять и выкинуть все в мусорку. Сейчас, даже если у меня отнять руки, взяв карандаш в зубы и тыкая по клавиатуре один символ в минуту я сделаю это лучше и быстрее, потому как 99% времени у меня уходит на размышления, а не на клацанье по клаве.
Спасибо большое, очень интересно. Сталкивался с подобными проблемами, но с другим профилем нагрузки и решал в основном программным путем. Может кому интересно будет:
Неравномерное распределение нагрузки по ядрам может происходить по разным причинам. На linux одним из самых эффективных решений — это фиксированный пул потоков, в каждом из котором свой цикл epoll, а слушающий сокет дублируется и может акцептиться в любом из потоков. После акцепта новый сокет продолжает обрабатываться в том же цикле потока. Все это работает очень шустро, т.к. нет оверхеда на всевозможные очереди и пр. Однако здесь есть подводный камень — по каким-то причинам, приоритет при акцепте, отдается потоку с меньшим id и в результате одни из потоков становиться более нагруженным. Если сервер работает в режиме “запрос на подключение”, то особых проблем не возникает даже на больших нагрузках, а вот если сервер работает с большим числом постоянных подключений при перезапуске будет сюрприз. Несколько сот тысяч клиентов одновременно пытается подключиться, и почти всех практически моментально заакцептит одно ядро, а у остальных ядер будет возможность подхватывать только новые подключения, в то время как первое будет перегружено. В этом случае имеет смысл сделать отдельный поток для акцептора и каким либо образом распределять сокеты по остальным потокам в зависимости от нагрузки.
Broken pipe может возникать при попытке записать в разорванное соединение. Например, в синхронном сервере (ответ на запрос формируется сразу в том же потоке) во время обработки запроса клиент закрывает соединение, т.е. к моменту вызова write клиент уже отключился, но вы не знаете об этом и получаете при записи Broken pipe. Вы конечно же узнаете о том, что сокет закрыт при следующем вызове epoll. В асинхронных серверах broken pipe, случаются реже, но также возможны. Если Broken pipe слишком много, то возможно, epoll цикл реализован не оптимально, например происходит попытка записать большой объем данных кусками в сокет без вызова epoll.
По мне так идеальная ОС, как и сами аппараты (были q10, z30 сейчас passport). Работа с сообщениями и почтой вне конкуренции. Андроид-приложения работ сносно, есть небольшой лаг при запуске, в последних версиях аккумулятор не особо жрут, могут работать в фоне и интегрируются в хаб. С многозадачностью там все ок, в основе QNX — это ОС жесткого реального времени (со своими плюсами и минусами). Не знаю как в других ОС, но можно запустить в браузере youtube и спокойно играть в Асфальт 8 без лагов, и переключаться. Будет ли приложение работать в фоне или встанет на паузу при переключении — это уже от разработчика зависит. В NFS вроде есть опция продолжать работать в фоне, спецом для демонстрации возможностей
В общем, если Jolla будет развиваться такими же темпами, то у неё есть все шансы занять достойное место в «пантеоне» мобильных ОС.
Нет шансов. Blackberry 10, например, идеальная для меня ОС во всех отношениях, эксперты и журналисты восторге, но не идет, не покупают. Нужны свистелки-перделки и инфраструктура. Поддержка андроид не спасает — зачем платить за эмуляцию, если можно чистый андроид взять.
>> Вот только в них легко можно встретить вложенность больше 31 уровня. И что делать?
На самом деле не легко, если только искусственно создать или спецом не оптимально, даже в самых монстрах не будет и 20. А 31 уровня более чем достаточно чтобы систематизировать все знания человечества.
логичное следствие — это нормальное распределение компетенций восприятия мира в мозгу конкретного индивида.
На примере: баба Маша лучше всех на деревне печет хлеб. Для нее все остальные, которые думают, что умеют печь хлеб — идиоты. Как правило подобная компетенция обществом признается и уважается.
Ложные компетенции, на примере противопоставления большинству. В сельский ДК приехал районный театр. Все пошли на спектакль, а дядя Ваня пошел на рыбалку, считая остальных стадом баранов, которые все равно ничего не понимают в искусстве, а пошли только из-за халявных билетов, что раздал председатель колхоза. Возможно, дядя Ваня и лучший на деревне рыбак, но явно не знаток искусства. Как правило подобные «компетенции» (в области искусства дяди Вани) обществом игнорируются, до тех пор пока индивид не начнет требовать их признания. Результатом таких попыток может стать жесткое противостояние общества и индивида.
А эта реплика объясняет не меньше
MTS-RUS — Gran Turismo!
говнокодил и активно изучал mouse-less. Я смеялся над умными книгами, где говорилось, что в среднем программист пишет 10 строк кода в день. Ха-ха! же несколько тысяч мог накодить! Когда я стал «старым» и медлительным, я анализировал проекты своей молодости которые ушли в продакшн и, с учетом отладки, тестирования, исправления багов и пр. — картина не радужная. В итоге получается, конечно не 10 строк в день, но и завершенными проектами эти поделки назвать сложно. А чтобы их завершить нужно… взять и выкинуть все в мусорку. Сейчас, даже если у меня отнять руки, взяв карандаш в зубы и тыкая по клавиатуре один символ в минуту я сделаю это лучше и быстрее, потому как 99% времени у меня уходит на размышления, а не на клацанье по клаве.Неравномерное распределение нагрузки по ядрам может происходить по разным причинам. На linux одним из самых эффективных решений — это фиксированный пул потоков, в каждом из котором свой цикл epoll, а слушающий сокет дублируется и может акцептиться в любом из потоков. После акцепта новый сокет продолжает обрабатываться в том же цикле потока. Все это работает очень шустро, т.к. нет оверхеда на всевозможные очереди и пр. Однако здесь есть подводный камень — по каким-то причинам, приоритет при акцепте, отдается потоку с меньшим id и в результате одни из потоков становиться более нагруженным. Если сервер работает в режиме “запрос на подключение”, то особых проблем не возникает даже на больших нагрузках, а вот если сервер работает с большим числом постоянных подключений при перезапуске будет сюрприз. Несколько сот тысяч клиентов одновременно пытается подключиться, и почти всех практически моментально заакцептит одно ядро, а у остальных ядер будет возможность подхватывать только новые подключения, в то время как первое будет перегружено. В этом случае имеет смысл сделать отдельный поток для акцептора и каким либо образом распределять сокеты по остальным потокам в зависимости от нагрузки.
Broken pipe может возникать при попытке записать в разорванное соединение. Например, в синхронном сервере (ответ на запрос формируется сразу в том же потоке) во время обработки запроса клиент закрывает соединение, т.е. к моменту вызова write клиент уже отключился, но вы не знаете об этом и получаете при записи Broken pipe. Вы конечно же узнаете о том, что сокет закрыт при следующем вызове epoll. В асинхронных серверах broken pipe, случаются реже, но также возможны. Если Broken pipe слишком много, то возможно, epoll цикл реализован не оптимально, например происходит попытка записать большой объем данных кусками в сокет без вызова epoll.
Нет шансов. Blackberry 10, например, идеальная для меня ОС во всех отношениях, эксперты и журналисты восторге, но не идет, не покупают. Нужны свистелки-перделки и инфраструктура. Поддержка андроид не спасает — зачем платить за эмуляцию, если можно чистый андроид взять.
На самом деле не легко, если только искусственно создать или спецом не оптимально, даже в самых монстрах не будет и 20. А 31 уровня более чем достаточно чтобы систематизировать все знания человечества.