Python интерпретируемый язык, Python использует внутри себя GIL, что делает невозможным параллелизацию на уровне самого кода
И по всей статье ни одного (даже плохого примера) с параллельностью. Есть и multiprocessing, и concurrent futures…
Да и тема «чистого» питона не раскрыта, можно генератор написать, можно map функцию использовать.
В общем посыл не понятен, что Вы хотели этой статьей показать, что питон медленный и не «параллельный»? Так мы это и так знаем)
Поэтому я и спросил. Вы пишите просто С/С++ оперируя чистым кодом, или вам часто приходится таки работать с железкой?
С железкой, не в плане, «накодогенераторить» а потом сидеть принтами дебагать, че из этого вышло.
В целом для чистого С, мне достаточно что Keil подстветит мне структуры, остальное вырабатывается по ходу работы, но все равно, я считаю что иметь для программирования встраиваемых систем монитор периферии, это огроменный плюс, который перекрывает «квадратность» редактора кода.
Эксперименты с IDE для embedd, я перестал делать после попытки завязаться с CooCooX, понял что проще попытатсья раскрыть потенциал знакомого инструмента, чем сидеть страдать в поисках.
Более того, мне компилятор кейл, как то более по душе, учитывая что он является официальным АРМ компиллером, а 30кб триального кода, на данный момент хватает за глаза.
В целом, я не хотел преподнести свои слова как агрессию, просто автор статьи, как новичек, непонятно за что боролся, настраивая Clion для редактирования кода, в ущерб скажем так «прозрачности» программирования и понимания. Я сам на первых парах лихорадочно трейсил даже функции в библиотеках (stl), сравнивая значения в регистрах с тем что нужно было мне, искал различные нюансы в написании кода, активно использовал эмулятор (например для исследования работы аналогового компаратора, и разных режимов ADC).
Мне кажется, что если ограничится работой с железом
А с чем Вы простите работаете, не с железом?
Мне кажется, не надо «редакторы» (atom/sublime), сравнивать с полноценной средой разработки для встраиваемых систем c присущим ей функционалом, ибо то что вы перечисляете есть ничто иное как фишки редактора, не более.
А я сравнил две IDE, и утверждал, что профита от Clion, кроме редактора — никакого.
Попробовал хваленый Keil — конечно получше блокнота
А вот щас, обидно было (с)
Я уже попробовал CLion для STM32 и у меня ровно обратные притензии:
— У меня вот (как и у 80% людей) ST-Link, че мне делать то с вашим Segger Debuger. Ответ — не дебажить.
— В отличии от Clion, Keil обладает хорошими сис. мониторами, которые позволяют контролировать процесс инициализации/пуска, эвенты/обработчики — что может Clion?
— В Keil есть отличный эмулятор, который позволяет не парится с дев бордой, или юзать функции МК которых нет на твоей борде (какой нить USB или FSMC и т.п.)
— Я использую продукты JetBrains, в частности PyCharm и меня задолбало, что за 4 часа работы IDE выжирает 2Гб ОЗУ (400 начальный это минимум), при всей своей «ненависти» к Keil его потребление неделями остается 40-50Мб, что позволяет мне его использовать ГДЕ угодно и КОГДА угодно.
— Keil имеет собственный репозиторий либ, которые добавляются простой галочкой в настройках.
Не срача ради, но все таки: Вам шашечки (подсветка, цветастость то да се) или таки ехать? (писать/дебагать под МК)
ЗЫ. Взял цв. тему с PyCharm, перегнал в Keil, получил 2 в 1, и Вам того советую. Кстати так и не понял что Вы называете «пакетами»?
С HR связываться как-то отдельно бесполезно. Нужно просто отправить ей резюме. Она сама свяжется, напишет, позвонит и отдаст ваше резюме тем, кто решает
Прохладная история… если HR не может просто ответить интересующую инфу по вакансии (в пределах разумного), то пусть ищет дальше.
Искренне не понимаю, когда люди заявляются ко мне в приват со стихами и откровениями на тему " Вы тот когда мы ищем", а на деле оказывается что и предложить то в общем нечего
ЗЫ. Я и крестиком вышивать умею, не только скрипты писать.
Так терпеть понимать, или таки помагать?
Я понимаю, когда у меня написано в профиле к примеру какие нить «ODBC, JDBC, OCI, OLE DB и ADO» это конечно да… тут и не всякий программист может понять. Но они даже логикой не руководствуются!
Написано авто-тестеровщик, они втюхивают девопсов/админов, написано Python — PHP.
Да чего говорить — очередной «экспонат» — http://clip2net.com/s/3MvIzhd
ЗЫ. Заметьте, «еще одно предложение» это не потому что я отказался, а потому что предложено было совсем не то, что мне подходит хоть как либо.
И это не признаки непроффесионализма — это нежелание вообще никак делать свою работу: изучать людей на рынке, для выявления потенциального кандидата.
HR отбирает резюме по формальным признакам, не связанным с глубоким анализом профессиональных знаний, умений и навыков
Моя задача понять — врёт ли кандидат, указывая в резюме огромный список ключевых слов или действительно он настолько крут.
Здесь противоречие или мне кажется?
Или Ваш анализ состоит в том что бы прочесть кандидату, то, что он сам написал в резюме?
Я думаю, что если HR не компетентный, то он не сможет задать вопрос, который может охарактеризовать уровень понимания кандидата о «ключевом слове»/технологии. или получится как всегда:
— Вы знаете язык программирования HTML
— HTML не язык программирования
— Вы нам не подходите
… понять и помогать ей сделать ее работу… быстро отвечать на письма, всегда подтверждать встречи отдельным письмом
чего? быстро отвечать?
Да они не могут найти в linkedIN твои контакты даже!
Дает оффер в приват, отвечаешь что детально обсудить желаешь в скайпе — все! HR пропала на неделю, объявляется с вопросом — дайте скайп который (....) написан в контактах профиля (кстати отличный тест на HR, читала она твой навыки или нет).
Поставил на фон в LinkedIN слово «Java» на белом фоне, и что? Летят оферы на Сишника/JSника/Ruby....facepalm
гм… еще раз хочу повторить свой пред. ответ: разделяйте лоад тестирование, по направлениям. Какую метрику Вы хотите знать? Ваш пример говорит лишь от отзыва части со статическими данными, которые по существу, должны вообще там крутится где-то на ngix и даже не лежать рядом с веб-приложением.
Второй момент, опять таки Ваш пример тестирует UI, а не сервер. И то что вы видите в браузере, есть следствие а не причина, более того — не самая достоверная метрика (у юзера может быть плохой канал, тупой браузер, тупой ПК). А лоад тест направлен на поиск причин на бек-енд стороне, в данном случае, можно было просто измерить время HEAD запроса и быть довольным… а если еще учитывать что, где то что-то там не догрузилось когда нужно (привет асинхронность), js запарился, страница не отрендерилась. Вины сервера тут нет, но плохой результат — на лицо. Как быть? Нужно разделять.
На самом деле, Ваши трактования не совсем верны. В первую очередь нужно менее широко, на этапе планирования, определить что Вы хотите измерить, ведь нагрузочное тестирование это целый пул смежных и не очень задач по тестированию системы.
В контексте несущего сервера, можно полностью отбросить статику и ресурсы от третьих сторон, так как нас интересует именно состояние нашего сервера, а не то, что происходит у юзера на UI (где-то UI не догрузился, где то js запарился)
Второй момент, недостаточно получить лишь HPS график, так как он не несет реальной пользы в исследовании сервера: скриптов, базы, кешей.
Из второго момента, так же следует понимать между абсолютной нагрузкой и взвешенной. Нередко проводя тесты, и приводя какие-то обоснованные результатами доводы я слышу «Тю, чувак, та такого быть не может — мы ж тут все кешируем/прелоадим/anyway» — как пример того что многие не понимают целей лоуд теста.
И одно из последних, для реально взвешенного лоуда, нельзя полагаться на методику «размазывания запросов», она естественно дают некие приближенные цифры производительности, но лучше всего в реальной системе, на проде, иметь некоторые метрики снятые всякими статистик сервисами (гуглометрика, яндекс метрика). При таком подходе, можно иметь взвешенную цифру запросов с секунду для одного реального пользователя, а его плотность запросов — как объект для построения своих тест-сьютов для лоуда-тестинга.
В целом, при простом тестировании в первом приближении, достаточно обзавестись лог-мониторингом (CPU/RAM), базы, и просто стабильно нагружать сервер одним запросом, уверен, даже при таком подходе Вы найдете большое количество недочетов в веб-приложении, и дальнейший анализ логов, уже более точно скажет куда нужно копать, для рефакторинга… у меня в 90% случаев, после первичного просмотра, дела сразу уходят в профилирование базы, изучения запросов, выдаче slow-log и его анализа.
И по всей статье ни одного (даже плохого примера) с параллельностью. Есть и multiprocessing, и concurrent futures…
Да и тема «чистого» питона не раскрыта, можно генератор написать, можно map функцию использовать.
В общем посыл не понятен, что Вы хотели этой статьей показать, что питон медленный и не «параллельный»? Так мы это и так знаем)
Аминь.
PS. Какая-то корявая копипаста, еще и с ошибками.
Поэтому я и спросил. Вы пишите просто С/С++ оперируя чистым кодом, или вам часто приходится таки работать с железкой?
С железкой, не в плане, «накодогенераторить» а потом сидеть принтами дебагать, че из этого вышло.
В целом для чистого С, мне достаточно что Keil подстветит мне структуры, остальное вырабатывается по ходу работы, но все равно, я считаю что иметь для программирования встраиваемых систем монитор периферии, это огроменный плюс, который перекрывает «квадратность» редактора кода.
Эксперименты с IDE для embedd, я перестал делать после попытки завязаться с CooCooX, понял что проще попытатсья раскрыть потенциал знакомого инструмента, чем сидеть страдать в поисках.
Более того, мне компилятор кейл, как то более по душе, учитывая что он является официальным АРМ компиллером, а 30кб триального кода, на данный момент хватает за глаза.
В целом, я не хотел преподнести свои слова как агрессию, просто автор статьи, как новичек, непонятно за что боролся, настраивая Clion для редактирования кода, в ущерб скажем так «прозрачности» программирования и понимания. Я сам на первых парах лихорадочно трейсил даже функции в библиотеках (stl), сравнивая значения в регистрах с тем что нужно было мне, искал различные нюансы в написании кода, активно использовал эмулятор (например для исследования работы аналогового компаратора, и разных режимов ADC).
А с чем Вы простите работаете, не с железом?
Мне кажется, не надо «редакторы» (atom/sublime), сравнивать с полноценной средой разработки для встраиваемых систем c присущим ей функционалом, ибо то что вы перечисляете есть ничто иное как фишки редактора, не более.
А я сравнил две IDE, и утверждал, что профита от Clion, кроме редактора — никакого.
Кажется мы стали забыть что такое IDE…
А вот щас, обидно было (с)
Я уже попробовал CLion для STM32 и у меня ровно обратные притензии:
— У меня вот (как и у 80% людей) ST-Link, че мне делать то с вашим Segger Debuger. Ответ — не дебажить.
— В отличии от Clion, Keil обладает хорошими сис. мониторами, которые позволяют контролировать процесс инициализации/пуска, эвенты/обработчики — что может Clion?
— В Keil есть отличный эмулятор, который позволяет не парится с дев бордой, или юзать функции МК которых нет на твоей борде (какой нить USB или FSMC и т.п.)
— Я использую продукты JetBrains, в частности PyCharm и меня задолбало, что за 4 часа работы IDE выжирает 2Гб ОЗУ (400 начальный это минимум), при всей своей «ненависти» к Keil его потребление неделями остается 40-50Мб, что позволяет мне его использовать ГДЕ угодно и КОГДА угодно.
— Keil имеет собственный репозиторий либ, которые добавляются простой галочкой в настройках.
Не срача ради, но все таки: Вам шашечки (подсветка, цветастость то да се) или таки ехать? (писать/дебагать под МК)
ЗЫ. Взял цв. тему с PyCharm, перегнал в Keil, получил 2 в 1, и Вам того советую. Кстати так и не понял что Вы называете «пакетами»?
Если это обзорная статья, то нужно говорить о всех вещах, а не только об очевидном.
Низачет, в общем то…
Прохладная история… если HR не может просто ответить интересующую инфу по вакансии (в пределах разумного), то пусть ищет дальше.
ЗЫ. Я и крестиком вышивать умею, не только скрипты писать.
Так терпеть понимать, или таки помагать?
Я понимаю, когда у меня написано в профиле к примеру какие нить «ODBC, JDBC, OCI, OLE DB и ADO» это конечно да… тут и не всякий программист может понять. Но они даже логикой не руководствуются!
Написано авто-тестеровщик, они втюхивают девопсов/админов, написано Python — PHP.
Да чего говорить — очередной «экспонат» — http://clip2net.com/s/3MvIzhd
ЗЫ. Заметьте, «еще одно предложение» это не потому что я отказался, а потому что предложено было совсем не то, что мне подходит хоть как либо.
И это не признаки непроффесионализма — это нежелание вообще никак делать свою работу: изучать людей на рынке, для выявления потенциального кандидата.
Здесь противоречие или мне кажется?
Или Ваш анализ состоит в том что бы прочесть кандидату, то, что он сам написал в резюме?
Я думаю, что если HR не компетентный, то он не сможет задать вопрос, который может охарактеризовать уровень понимания кандидата о «ключевом слове»/технологии. или получится как всегда:
— Вы знаете язык программирования HTML
— HTML не язык программирования
— Вы нам не подходите
чего? быстро отвечать?
Да они не могут найти в linkedIN твои контакты даже!
Дает оффер в приват, отвечаешь что детально обсудить желаешь в скайпе — все! HR пропала на неделю, объявляется с вопросом — дайте скайп который (....) написан в контактах профиля (кстати отличный тест на HR, читала она твой навыки или нет).
Поставил на фон в LinkedIN слово «Java» на белом фоне, и что? Летят оферы на Сишника/JSника/Ruby....facepalm
Но если я деформирую пространство, рядом со «спутниками=электронами» они ведь тоже «ускоряются»?
Второй момент, опять таки Ваш пример тестирует UI, а не сервер. И то что вы видите в браузере, есть следствие а не причина, более того — не самая достоверная метрика (у юзера может быть плохой канал, тупой браузер, тупой ПК). А лоад тест направлен на поиск причин на бек-енд стороне, в данном случае, можно было просто измерить время HEAD запроса и быть довольным… а если еще учитывать что, где то что-то там не догрузилось когда нужно (привет асинхронность), js запарился, страница не отрендерилась. Вины сервера тут нет, но плохой результат — на лицо. Как быть? Нужно разделять.
В контексте несущего сервера, можно полностью отбросить статику и ресурсы от третьих сторон, так как нас интересует именно состояние нашего сервера, а не то, что происходит у юзера на UI (где-то UI не догрузился, где то js запарился)
Второй момент, недостаточно получить лишь HPS график, так как он не несет реальной пользы в исследовании сервера: скриптов, базы, кешей.
Из второго момента, так же следует понимать между абсолютной нагрузкой и взвешенной. Нередко проводя тесты, и приводя какие-то обоснованные результатами доводы я слышу «Тю, чувак, та такого быть не может — мы ж тут все кешируем/прелоадим/anyway» — как пример того что многие не понимают целей лоуд теста.
И одно из последних, для реально взвешенного лоуда, нельзя полагаться на методику «размазывания запросов», она естественно дают некие приближенные цифры производительности, но лучше всего в реальной системе, на проде, иметь некоторые метрики снятые всякими статистик сервисами (гуглометрика, яндекс метрика). При таком подходе, можно иметь взвешенную цифру запросов с секунду для одного реального пользователя, а его плотность запросов — как объект для построения своих тест-сьютов для лоуда-тестинга.
В целом, при простом тестировании в первом приближении, достаточно обзавестись лог-мониторингом (CPU/RAM), базы, и просто стабильно нагружать сервер одним запросом, уверен, даже при таком подходе Вы найдете большое количество недочетов в веб-приложении, и дальнейший анализ логов, уже более точно скажет куда нужно копать, для рефакторинга… у меня в 90% случаев, после первичного просмотра, дела сразу уходят в профилирование базы, изучения запросов, выдаче slow-log и его анализа.