Пользователь
Исследование исполняемого файла можно разделить на три этапа: поверхностный, глубокий, хирургический. На первом мы малыми силами собираем информацию о подопытном файле. Под «малыми силами» я подразумеваю легкие в использовании и широко распространенные средства анализа. В этой статье мы поговорим о них и для наглядности взломаем несложную защиту.
x86_64 Linux и в то же время начал погружаться в исходный код ядра Linux.
В одной конторе соискателю на позицию Senior C# developer выдали тестовое задание: отсортировать файл со строками определенного формата.
Требования такие:
* Формат строки: число, точка, пробел, далее любые символы до конца строки.
* Порядок сортировки — сначала сортируем текстовой части строки, потом по числу если текстовые части совпадают.
* Кодировка — UTF-8.
* Размер файла — 100гб - гарантированно больше объема ОП.
Должно отработать за 1 час на машине проверяющего, вряд ли там будет супер-быстрый SSD и огромное количество оперативной памяти.
Как и многие другие программисты, узнав о таком тестовом задании, я возмутился. Внешнюю сортировку слиянием практически всех проходили в ВУЗе, но практически никто никогда не писал её. Задача очень непрактическая и непонятно какие навыки проверяет. Так мне казалось.
Эта задача вызвала бурные обсуждения о способах её решения. Многие программисты, причисляющие себя к рангу senior, предложили использовать базы данных, ибо не барское это дело - вручную писать алгоритмы сортировки. Некоторые даже попытались сделать решение на Apache Spark. Однако никто до конца задачу не решил, ибо мало кому удалось отсортировать в нужном порядке даже 10ГБ файл менее чем за 15 минут без SSD.
Я подумал, что стоит решить задачу до конца с помощью программирования, и тоже причислить себя к рангу senior developer.
Чтобы стать экспертом в этом вопросе, мне пришлось провести целый ряд исследований. В итоге я составила чек-листы по самым популярным странам, собрала советы у ветеринаров и проанализировала успешные и неуспешные кейсы. Делюсь статистикой и полезными ссылками. И конечно, фотографиями котов и собак.
Привет, Хабр! Меня зовут Михаил Полукаров, я занимаюсь разработкой desktop-версии в команде VK Teams. В первой части я рассказывал о том, как использовать маски и создавать сложные многослойные окна. Под катом этой статьи мы продолжим исследовать возможности Qt Framework, рассмотрим полупрозрачность и управление буксировкой окна, а также реализуем интересный спецэффект. В конце статьи рассмотрим, как можно применить на практике весь, изложенный в этом цикле статей, материал для создания современного демонстрационного приложения.
Нам давно хотелось рассказать сообществу о том, как мы разрабатываем фичи в KMM-проектах. В статье описан полный путь интеграции gRPC в мультиплатформенный проект, пройденный нашей командой. Он включает и создание проекта, и настройку фичи в проекте. Также мы очень хотим продвигать мультиплатформу именно в среде iOS-разработчиков, поэтому бонусом делаем особый акцент на этой платформе.
Придумывать интерфейс интересно. Похоже на головоломку. Вот что получается для Dgrm.net.
Вот мы и вернулись! С "небольшим" опозданием, но нам есть чем оправдаться ;) В прошлом году мы строили и запускали самодельные стратостаты с целью привезти видео в 4k с высоты 30+ километров. В этом году мы, наконец-то, достигли всех поставленных целей и привезли бескомпромисный результат. Получилось опять "длинно", но я сокращал как мог. Будет много фоток, пару видео и даже гифки.
Меня зовут Виктор, я разрабатываю страницу результатов поиска Яндекса. Несмотря на внешнюю простоту, поисковая выдача — сложная штука: на каждый запрос генерируется своя уникальная страница, на которой в зависимости от запроса может присутствовать блок Картинок, Карты, Переводчик, видеоплеер и многие другие компоненты. Все они должны запускаться и работать в памяти обычных бюджетных телефонов, которые использует большинство наших пользователей. Браузерам должно хватать ресурсов, чтобы пользователь не видел вот такого:
На своих серверах мы должны генерировать сотни миллионов уникальных страниц в сутки — это сложнее, чем просто отдавать одни и те же ресурсы. Генерация страницы не должна быть слишком требовательной к памяти сервера.
Разрабатывая проект на JavaScript (TypeScript, ClojureScript или каком-то другом языке, транслируемом в JavaScript), мы привыкли создавать объекты, массивы, строки и вообще писать код, как будто память бесконечна. Это не так. Я расскажу о видах проблем с памятью, о том, какие ограничения мы часто забываем и как их можно преодолеть. В ответ браузеры и пользователи скажут вам спасибо.
Что может быть лучше десятка пары часов проведенных с дженериками и compile time safety в C#?
В этом очерке о единицах измерения, а точнее о том, как можно сделать потенциально очень крутую систему с полной проверкой на этапе компиляции, автоматической конверсией единиц измерения, кастомизированностью и расширяемостью во все стороны! Да, и еще неплохой производительностью. И вообще!
Одним из основных преимуществ Java является автоматизированное управление памятью с помощью встроенного сборщика мусора (или сокращенно GC). GC неявно заботится о выделении и освобождении памяти и, таким образом, способен решать большинство проблем, связанных с ее утечкой.
Хотя GC эффективно обрабатывает значительную часть памяти, он не гарантирует надежного решения проблемы с ее утечкой. GC достаточно умен, но не безупречен. Утечки памяти все еще могут закрасться даже в приложения, созданные добросовестным разработчиком.
По-прежнему возможны ситуации, когда приложение создает значительное количество лишних объектов, расходуя ресурсы памяти, что иногда приводит к его полному отказу.
Утечки памяти — это настоящая проблема в Java. В этом руководстве мы рассмотрим, каковы потенциальные причины утечек, как распознавать их в рантайме и как справиться с ними в нашем приложении.
main.
Эта статья будет полезна, если вы начинаете проект, который может перерасти в HL (HighLoad) или у вас уже есть проект, который имеет высокую нагрузку. Каждый пункт этого чек-листа поможет избежать определенных проблем, возникающих в процессе эксплуатации таких систем. И хотя некоторые пункты могут показаться довольно очевидными, а иные даже лишними, я рекомендую ознакомиться со всем списком, т.к. судя по статьям на хабре, периодически с некоторыми из этих проблем встречаются компании, которые уже обрели некоторую популярность. Дополняя систему каким то компонентом довольно просто забыть о таких вещах, как KeepAlive между двумя сервисами, а процессы изменения и дополнения в IT происходят постоянно.
Я не буду тут говорить про вертикальное и горизонтальное масштабирование, о микросервисах, балансировке нагрузки, важности тестирования и прочем таком. Будем считать, что читатели все это уже знают, ну а если кто-то не знает, пусть гуглит сейчас. Кроме того, тут вы не найдете инструкции, как проектировать и строить такие системы, цель этой статьи проста - собрать воедино какой-никакой удобоваримый чек-лист для HighLoad системы. Пункты взяты не с потолка - это результат исследовательской деятельности перемежающейся с личным опытом.
В предыдущей статье я рассказал про пластичность мозга. Сегодня предлагаю первые три техники ее тренировки. Идея очень простая: представьте себе, что ваша работа состоит не в том, чтобы строить окружающую жизнь. И не в том, чтобы вручную управлять карьерой и взаимоотношениями в окружающем мире, тратя на это ограниченный ресурс нашей силы воли.
Идея в том, чтобы выстроить систему — некую совокупность процессов, которые будут воспроизводиться и обеспечивать необходимый результат с меньшими усилиями. Сила воли будет тратиться для настройки шаблонов наших нейромашин. А качество шаблонов напрямую связано с качеством нашей жизни: именно они позволяют нам показывать высокие результаты в работе, личной жизни, заботе о себе и построении всей жизни в те моменты, когда мы не следим за этим осознанно.
