Рубрика «Storm»

Привет, GT! Новый год кое-где уже настал, к кому-то ещё следует, ну а у меня для вас новогодний подарок. Большой пост про шесть игровых мышей в разной ценовой категории от шести разных вендоров. Нужна новая боевая подруга? Не определились с подарком на Новый год для себя? Выбирайте претендента и вперёд! :)

Мышиная гирлянда: шесть игровых девайсов на одном поле - 1

Сегодня в номере: ASUS Gladius, Mad Catz R.A.T.7, Cooler Master Storm Reaper, Defender Warhead, Roccat Tyon и SteelSeries Rival.
Читать полностью »

Развитие информационных технологий сказывается на разработке всего спектра программного обеспечения (ПО). Не обходит оно стороной и вредоносные программы. Можно выделить основные приемы, применяемые при разработке «передового» вредоносного программного обеспечения (ВПО).
Читать полностью »

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).


Разработка через страдание Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js