Спасибо за ответ :) Когда долго чем-то занимаешься забываешь, что очевидные для тебя вещи не очевидны для других.
По поводу логов, логи важны, логи нужны, но они так же могут являться большой проблемой для производительности это факт. Поэтому как минимум нужно поддерживать различный log level в своих сервисах (debug, warning, info, error), ещё лучше использовать специализированные пакеты для логов в которых был сделан упор на производительность. Так же для меня очевидно, что разработка идёт в разных изолированных окружениях local, dev, test, stage, prod. Так вот если на local, dev, test допускается использовать log level = debug, то для stage и prod это уже не допустимо. Так же как не допустимо вылить на stage сервис с memory leak.
Мой совет по debug logs на функции, касается только local и dev окружения. Для stage и prod это не допустимо.
Привет минуса :) Как я написал в последнем абзаце "дать конкретные советы невозможно, каждый проект индивидуален", описать все возможные кейсы не реально. Например Мартин Фаулер издал 8 книг с 1996 года в каждой из которых по 400-500 страниц примеров кода и продолжает вести свой блог по рефакторингу и архитектуре. На сайте govnokod.ru сейчас 28 000 записей :)
"консольного наблюдения достаточно" - если мы говорим про команду top, её большой минус это отсутсвие визуализации изменения значения во времени. Можно пропустить тот момент когда было 10 мегабайт потом стало резко 300, потом 20, но 20 ведь тоже не нормально должно же быть 10. Или как понять что происходило с памятью в течении 2х месяцев эксплуатации сервиса в продакшене, кушает ли он память?
Я могу лишь дать базовые советы по отладке. Пишите debug логи в начале и конце функции, например через defer, так вы сможете отследить ее завершение и понять по логам сервиса при каких обстоятельствах он упал или память начала расти. Не стесняйтесь в лог выводить переменные, например идентификатор клиента, который подключился, параметры "флаги" запуска сервиса. Обычно в логах присутствует timestamp, посмотрев на графике, когда начался рост и почитав логи в ELK за этот период, можно будет понять, что примерно происходило в программе и попытаться воспроизвести этот сценарий. Внимательно проверяйте все ли вы открытое закрываете, особенно это хорошо проявляется при отладке graceful shutdown. Например известный кейс с "close response body". Если интерфейс предоставляет метод close или подобный возьмите за правило после его инициализации писать defer *.close()
По поводу везения — ну если ты руководитель проекта закладывать время на тех долг нужно и жизненно необходимо. Я например после релиза фичи закладывал спринт на тех долг неделю или две в зависимости от ситуации. Если ты обычный разработчик — твое свободное время — время заниматься рефакторингом, главное что бы это было не в разрез твоей производительности и срокам.
Если рефакторинг занимает больше времени чем выполнение текущих задач — его стоит отложить на тот самый специальный спринт (если он есть).
С развитием навыков и знаний (про SOLID про DRY, TDD, BDD, DDD и тд) у тебя уже изначально не будет получаться «лапшекод», но нужно понимать грань между временем решения задачи и времени на проектирование этого решения. В случае если ты обычный разработчик а не архитектор, если время проектирования решения занимает больше чем время решения — лучше выбрать монолит, грубо говоря если сходу не можешь прикинуть как что должно быть правильно — накидай монолит, который в этот же день начни раскидывать по «правильному», главное что бы он заработал и решал поставленную задачу :)
Не осилил статью, но расскажу немного про преждевременную оптимизацию. На практике очень часто бывает так что требования меняются по ходу разработки и жизни проекта. Вы много часов потратите на "переиспользуемые" блоки, а потом требования изменятся. Напишите сначала монолит, который возможно и некрасивый, но работает. После того как проект устаканится или вам выделят время на рефакторинг занимайтесь им. Позже с опытом у вас само собой появятся эти "перписпользуемые" практики написания кода.
Как по мне TS незаменим на бекенде, для компонентов если они "правильно" написаны (pure function) TS оверхед, который усложняет и замедляет разработку. ИМХО.
Если вас действительно интересует качество вашего кода, читайте книжки: "совершенный код", "чистый код". "Рефакторинг" Фаулера кстати очень занятная книга по теме.
Скорость чтения/записи на диск это то во что ты упираешься пиши хоть на ассемблере. Если твоя программа работает с файлами, выше этой цифры не прыгнешь. Если опускаться на уровень операционной системы она тоже работает с файловой системой, например когда ты запрашивает новый срез memory mapped файла. Не возьмусь утверждать, но вроде винда скидывает дамп памяти на диск при выходе за границы виртуальной памяти процесса. JS код это очень-очень много мелких файлов (node_modules). Билд на SSD и HDD небо и земля, личный опыт.
Ну и зачем? Ребята из root-me старались, подготавливали материал, а вы делаете «решебник». Смысл то в том что бы побудить людей к исследованию и изучению чего-то нового, а вы убиваете всю интригу.
let result
if (variant === 'h1') result = styles.h1
else if (variant === 'h2') result = styles.h2
else if (variant === 'h3') result = styles.h3
else if (variant === 'h4') result = styles.h4
else if (variant === 'h5') result = styles.h5
else if (variant === 'h6') result = styles.h6
else if (variant === 'title') result = styles.title
else if (variant === 'subheading') result = styles.subheading
O_o не делайте так никогда, это пример плохого кода. Используйте switch в подобных конструкциях.
Делать было нечего дело было вечером. Решил протестировать простые сервера на node.js и golang через ab и JMeter — github.com/Garik-/http-benchmark
Библиотека µWebSockets.js ab не смог протестировать её, а JMeter показал результаты хуже чем обычный встроенный http на node.js.
Вы можете склонировать репозиторий и повторить тесты самостоятельно, пишите в issue пожелания и свои результаты.
Для меня основной критерий — скорость обработки запроса, как у python обстоят дела со скоростью сетевых запросов? Использует ли он неблокирующие сокеты или какие другие механихзмы? Есть ли смысл смотреть в сторону python если мне допустим необходимо обойти 3 000 000 сайтов?
Писал подобное на winAPI в далеком 2010 году, программа была установлена в компьютерной аудитории и использовалась лаборантами для коллекционирования курсовых, дипломов и недописанных статей, книг преподователей, которые использовали этот компьютер для показа презентаций.
К сожалению исходников я не нашел (винт приказал долго жить), остались лишь воспоминания в блоге
Программа висит в памяти и с интервалом в минуту проходится по всем логическим дискам, если это флешка запрашивается ее серийный номер — программа сравнивает записи в реестре о последнем копировании с данной флешки и если прошло больше суток запускается рекурсивная функция копирования. Копирование производится на доступный для записи диск с условием, что на диске достаточно свободного места.
Практически 10 лет занимаюсь веб разработкой, в качестве программиста, но в начале пути интересовался веб дизайном (обучался в худ. школе, есть навыки).
ИМХО В данном переводе из полезного только ссылки. «Я не дизайнер, но научу вас, как делать дизайн». Это как?
В той же художественной школе для того что бы нарисовать человека изучают анатомию, места крепления мышц, рисуют кучу эскизов, что бы передать на бумагу естественные пропорции и положения тела. А здесь «палка палка огуречик вот и вышел человечек».
Шаблонный макет в 3 колонки во flat стиле с «ворованными» иконками и цветовой гаммой могут сделать многие, но придумать идею, свой стиль, вдохнуть жизнь в макет, для этого нужен талант и творческое начало. У меня просто нет слов, что бы описать мое возмущение…
Какого размера? Ведь размер получаемых данных заранее не известен (исходя из условия задачи).
По поводу буферизации чтения записи, это тема отдельного разговора (http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx), особенно если дело касается асинхронности.
Не знаю специфики задачи, но если есть «бесконечный» буфер, когда не известен размер получаемых/обрабатываемых данных использую временные файлы (temporary file). В системе Windows временный файл, это по сути тот-же MMF, но если его размер превышает размер виртуального адресного пространства, он скидывается на диск. Про *nix не знаю.
Алгоритм получается такой: получили в буфер пакет, нашли сигнатуру начала и его длину, создали временный файл, записали туда данные, получили в буфер следующий пакет, во временный скинули данные. Пакет закончился, переместили курсор на начала файла, размер нам известен — анализируем. Ну и так как временный файл = память (для ОС Windows) — все работает быстро.
Гайд по поиску и устранению утечек памяти в Go сервисах
Спасибо за ответ :) Когда долго чем-то занимаешься забываешь, что очевидные для тебя вещи не очевидны для других.
По поводу логов, логи важны, логи нужны, но они так же могут являться большой проблемой для производительности это факт. Поэтому как минимум нужно поддерживать различный log level в своих сервисах (debug, warning, info, error), ещё лучше использовать специализированные пакеты для логов в которых был сделан упор на производительность. Так же для меня очевидно, что разработка идёт в разных изолированных окружениях local, dev, test, stage, prod. Так вот если на local, dev, test допускается использовать log level = debug, то для stage и prod это уже не допустимо. Так же как не допустимо вылить на stage сервис с memory leak.
Мой совет по debug logs на функции, касается только local и dev окружения. Для stage и prod это не допустимо.
Гайд по поиску и устранению утечек памяти в Go сервисах
Привет минуса :) Как я написал в последнем абзаце "дать конкретные советы невозможно, каждый проект индивидуален", описать все возможные кейсы не реально. Например Мартин Фаулер издал 8 книг с 1996 года в каждой из которых по 400-500 страниц примеров кода и продолжает вести свой блог по рефакторингу и архитектуре. На сайте govnokod.ru сейчас 28 000 записей :)
"консольного наблюдения достаточно" - если мы говорим про команду top, её большой минус это отсутсвие визуализации изменения значения во времени. Можно пропустить тот момент когда было 10 мегабайт потом стало резко 300, потом 20, но 20 ведь тоже не нормально должно же быть 10. Или как понять что происходило с памятью в течении 2х месяцев эксплуатации сервиса в продакшене, кушает ли он память?
Я могу лишь дать базовые советы по отладке. Пишите debug логи в начале и конце функции, например через defer, так вы сможете отследить ее завершение и понять по логам сервиса при каких обстоятельствах он упал или память начала расти. Не стесняйтесь в лог выводить переменные, например идентификатор клиента, который подключился, параметры "флаги" запуска сервиса. Обычно в логах присутствует timestamp, посмотрев на графике, когда начался рост и почитав логи в ELK за этот период, можно будет понять, что примерно происходило в программе и попытаться воспроизвести этот сценарий. Внимательно проверяйте все ли вы открытое закрываете, особенно это хорошо проявляется при отладке graceful shutdown. Например известный кейс с "close response body". Если интерфейс предоставляет метод close или подобный возьмите за правило после его инициализации писать defer *.close()
Продолжать можно бесконечно долго :)
Удвойте скорость написания кода на React с помощью этих простых трюков
Если рефакторинг занимает больше времени чем выполнение текущих задач — его стоит отложить на тот самый специальный спринт (если он есть).
С развитием навыков и знаний (про SOLID про DRY, TDD, BDD, DDD и тд) у тебя уже изначально не будет получаться «лапшекод», но нужно понимать грань между временем решения задачи и времени на проектирование этого решения. В случае если ты обычный разработчик а не архитектор, если время проектирования решения занимает больше чем время решения — лучше выбрать монолит, грубо говоря если сходу не можешь прикинуть как что должно быть правильно — накидай монолит, который в этот же день начни раскидывать по «правильному», главное что бы он заработал и решал поставленную задачу :)
Пишите библиотеки вместо сервисов (если это возможно)
Удвойте скорость написания кода на React с помощью этих простых трюков
Не осилил статью, но расскажу немного про преждевременную оптимизацию. На практике очень часто бывает так что требования меняются по ходу разработки и жизни проекта. Вы много часов потратите на "переиспользуемые" блоки, а потом требования изменятся. Напишите сначала монолит, который возможно и некрасивый, но работает. После того как проект устаканится или вам выделят время на рефакторинг занимайтесь им. Позже с опытом у вас само собой появятся эти "перписпользуемые" практики написания кода.
Как по мне TS незаменим на бекенде, для компонентов если они "правильно" написаны (pure function) TS оверхед, который усложняет и замедляет разработку. ИМХО.
Если вас действительно интересует качество вашего кода, читайте книжки: "совершенный код", "чистый код". "Рефакторинг" Фаулера кстати очень занятная книга по теме.
Web Cryptography API: пример использования
Зачем тащить в проект лишнюю зависимость, если ты в состоянии написать нужную тебе реализацию?
Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода
Скорость чтения/записи на диск это то во что ты упираешься пиши хоть на ассемблере. Если твоя программа работает с файлами, выше этой цифры не прыгнешь. Если опускаться на уровень операционной системы она тоже работает с файловой системой, например когда ты запрашивает новый срез memory mapped файла. Не возьмусь утверждать, но вроде винда скидывает дамп памяти на диск при выходе за границы виртуальной памяти процесса. JS код это очень-очень много мелких файлов (node_modules). Билд на SSD и HDD небо и земля, личный опыт.
Мне 14, и я совмещаю школу с работой в ИТ
C, C++ и DotNet decompile — основы реверса. Решение задач на реверсинг с r0от-мi. Часть 1
14 советов по написанию чистого React-кода. Часть 1
O_o не делайте так никогда, это пример плохого кода. Используйте switch в подобных конструкциях.
После подобного и
../../../../../../../../../../, невозможно воспринимать статью всерьёз. Webpack alias, автору для справки.Всегда ли Node.js будет медленнее, чем Golang?
Библиотека µWebSockets.js ab не смог протестировать её, а JMeter показал результаты хуже чем обычный встроенный http на node.js.
Вы можете склонировать репозиторий и повторить тесты самостоятельно, пишите в issue пожелания и свои результаты.
Работа с ЖК индикатором на отладочной плате STM32L-Discovery
Парсим мемы в питоне: как обойти серверную блокировку
Пишем программу для кражи данных с USB-носителя в Windows
К сожалению исходников я не нашел (винт приказал долго жить), остались лишь воспоминания в блоге
«То, чего на белом свете вообще не может быть…»
Транзисторный усилитель класса А своими руками
Какие диоды ставились в мосты (характеристики)? Зачем использовался серебряный припой? — это как и куда? Какие вы использовали разъемы для подключения колонок и входного сигнала?
Заметки о дизайне для разработчиков
ИМХО В данном переводе из полезного только ссылки. «Я не дизайнер, но научу вас, как делать дизайн». Это как?
В той же художественной школе для того что бы нарисовать человека изучают анатомию, места крепления мышц, рисуют кучу эскизов, что бы передать на бумагу естественные пропорции и положения тела. А здесь «палка палка огуречик вот и вышел человечек».
Шаблонный макет в 3 колонки во flat стиле с «ворованными» иконками и цветовой гаммой могут сделать многие, но придумать идею, свой стиль, вдохнуть жизнь в макет, для этого нужен талант и творческое начало. У меня просто нет слов, что бы описать мое возмущение…
STM32L-DISCOVERY + FDD
C++ и копирование перекрывающихся областей памяти
Какого размера? Ведь размер получаемых данных заранее не известен (исходя из условия задачи).
По поводу буферизации чтения записи, это тема отдельного разговора (http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx), особенно если дело касается асинхронности.
C++ и копирование перекрывающихся областей памяти
Алгоритм получается такой: получили в буфер пакет, нашли сигнатуру начала и его длину, создали временный файл, записали туда данные, получили в буфер следующий пакет, во временный скинули данные. Пакет закончился, переместили курсор на начала файла, размер нам известен — анализируем. Ну и так как временный файл = память (для ОС Windows) — все работает быстро.