Уж простите за пафосный заголовок, но раз пошла такая пьянка, то продолжим. Мне лично такие посты нравились всегда.

Итак, речь пойдёт про уязвимость известного в Мск (да и не только) провайдере Beeline. Многие помнят его под именем Corbina. Без сомнения, это один из передовых интернет провайдеров, с большой и хорошей историей. В своё время он был спасением, благодаря качественному и быстрому инету, интранет сетям и т.п. В настоящий момент сотрудники провайдера в курсе уязвимостей и самые критичные уже закрыты. Однако, уверен, многие откроют для себя много нового и интересного. Тем более, что техника применима практически к любому провайдеру.

Давным-давно мы с друзьями играли в Starcraft по диалапному модему. Я часто проигрывал, пока не прочитал на одной из BBS фразу, которая всё поменяла. Принцип очень простой: в стратегиях реального времени выигрывает тот, кто постоянно атакует. Нужно было научиться мыслить категориями постоянного создания угроз.

К чему я это. Есть такой мужик — Дэвид Сирлин. Киберспортсмен, чемпион по Street Fighter, гейм-дизайнер, настольщик, киберспортивный тренер. У него есть целая теория на тему того, как тренироваться и играть так, чтобы выигрывать. Универсальная, применима ко всем играм. Ниже — основные тезисы первой части и мои комментарии. Прочитать про основные вещи из книги будет интересно и с точки зрения GameDev (в особенности — балансировки), и просто по жизни.

Сейчас на русском нет актуального учебника по программированию для детей (исправьте, если не прав). Поэтому я решил написать его и выложить в открытый доступ.
 

Продолжаем тему интересного на .Net, от чего мир Java будет посмеиваться (хотя у них это также возможно сделать), а приверженцы С++ говорить: «чего они только не сделают чтобы не учить C++».

В данной заметке мы напишем по сути – простенькое ядрышко профилировщика памяти для платформы .Net, который будет снимать дамп с SOH кучи (а в перспективе и с LOH).

Для написания статьи нам понадобится код из статьи Получение указателя на объект .Net и Ручное клонирование потока (измерение размера объектов).

Наши цели на сегодня:

• Научиться итерировать кучу .Net
• Научиться находить начало кучи .Net
• Попробовать сытерировать все объекты чужого домена.

Ссылка на проект в GitHub: DotNetEx

Ссылка на проект в GitHub: DotNetEx

На множественных ресурсах время от времени задается вопрос. Можно ли сделать отгружаемые сборки с текущего домена? Так, чтобы попользовался и «давай, до свидания!»? Везде и всегда ответ, который давался – это «нет». Ведь единственное, что можно выгрузить – это домен. Соответственно, если хочется наладить отгрузку, сборку надо помещать в домен, и налаживать между доменами взаимодействие через сериализуемые типы. А это — очень медленное взаимодействие. А мы скажем так. Можно. С ньюансами. Загружать мы будем также в отдельный домен. Но отменим сериализацию при вызове методов между доменами.

Вопросы, которые мы будем решать:

• Создание домена с возможностью отдачи объекта из домена в родительский
• Выгрузка сборки

Многие приложения весьма долго стартуют из-за того, что инициализация тяжелых компонентов требует времени на загрузку данных. В какой-то момент возникло логичное желание сократить время старта за счет асинхронного выполнения части операций.

Под приложением я сейчас имею ввиду довольно «толстый» бекенд некоего интернет-сервиса, которому для старта необходимо подгрузить немало всяких бизнес-кешей до того, как нода попадет в балансировщик нагрузки, избавляя первых пришедших пользователей от томительного ожидания, а дежурного администратора от алерта о том, что приложение отвечает слишком медленно.

Асинхронную логику я решил реализовывать через механизм async/await, а готовые к работе компоненты регистрировать в Unity.

Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 2008го, и опыта хорошего и плохого у меня накопилось достаточно много. Цель данной публикации — показать разницу между простыми сотрудниками и фрилансерами, а также — показать основные организационные проблемы, которые возникают при разработке и проектировании программного обеспечения. Я надеюсь, что этот пост поможет прояснить некоторые производственные моменты, которые могли бы быть не совсем очевидны для разработчиков и их руководства.

Суждения в данной статье субъективны — сплошная концентрированная «отсебятинка».
Они основаны на моём личном опыте и опыте людей с которыми я общаюсь.

В России убытки от мошеннических операций с 2006 по 2013 год выросли в 10 раз (по отчетам FICO)! В 2012 году по отчетам Cybersource 2013 электронное мошенничество стоило индустрии интернет-коммерции 3.5 миллиарда долларов, и это только в США. Что составляет 0.9% от оборота.

Две причины, по которым 0.9% — неприемлемо большая цифра:

• Потеря 0.9% от доходов составляет одну восьмую часть среднего по индустрии показателя чистой прибыли (6.8%). Без мошенничества, сфера Интернет-торговли станет прибыльнее почти на 13%.
• Бизнес мог бы реинвестировать эту прибыль, используя способы, которые помогли бы клиентам и экономике. Например, предложение более низких цен или наем большего количества сотрудников.

Страдает репутация продавцов, они вынуждены делать возвраты и выделять ресурсы для работы со своими худшими клиентами. Покупатели получают повышение цен, остаются недовольны длинными страницами оформления заказа и дольше ждут их доставки.

В этом году на хабре очень популярна тема торговли на разного рода биржах(фондовых, валютных и т.д.) в частности автотрейдинг. В большинстве публикаций авторы рассматривают работу с API бирж или терминалов и в комментариях пользователи просят показать не просто абстрактные примеры, а конкретных роботов, ссылаясь на то, что на рынке трейдер трейдеру не конкурент и все смогут заработать.

Сначала я хочу показать возможные методы монетизации роботов, а после вернутся к вопросу конкуренции.

В нескольких последних публикациях нашего блога мы рассказывали об уязвимостях сетей мобильной связи, а также о возможностях прослушки на основе таких уязвимостей. При этом читатели в комментариях не раз выражали сомнение в том, что можно вот так легко попасть во внутреннюю технологическую сеть оператора. Однако свежий пример с троянцем Regin показывает, что это не только возможно, но и делалось систематически уже много лет.

Основное

• Reference Source для .NET 4.6 перелицензируется под MIT;
• В дальнейшем фреймворк будет с открытыми исходниками и поставляться по частям через NuGet, можно будет с приложением поставлять свою сборку, которая будет изолирована от всего остального;
• Разработка переезжает на GitHub;
• Скоро откроют исходники рантайма, включая RyuJit и сборшик мусора;
• Для всего этого счастья планируется официальная поддержка никсов.

​

​

Mono не то чтобы больше не нужен, в дальнейшем с ними будут плотно сотрудничать для портирования, вероятно, этот стек будет некоторое время поставляться в составе Mono, так как открыто ещё далеко не всё и для полноценной работы потребуются вещи из его состава.

Сегодня в Нью Йорке проходит конференция Microsoft Connect(), на которой анонсированы новые продукты и технологии. Выпущена предварительная версия Visual Studio 2015, специальная бесплатная редакция Visual Studio Community 2013, Visual Studio 2013 update 4, открывается исходный код .NET Server Core, выпущена предварительная версия .NET 2015, обновлены инструменты кросс-платформенной разработки на базе Apache Cordova, в Visual Studio появился эмулятор ОС Android. Это действительно новый этап в развитии инструментов разработки Microsoft, и мы рады рассказать о деталях.

Человеку давно свойственно интересоваться окружающим миром и находить объяснения тому окружающим вещам и событиям. Собственно, без этого человек не стал бы человеком. На базе верований, мифов развивалась сначала религия, а потом — и современная наука, которая уже весьма успешно объясняет окружающий мир от очень малых до впечатляющих масштабов. Но всегда оставались люди, которые противились прогрессу и распространяли устоявшиеся мифы, уверяя, что они отвечают на все вопросы и незачем двигаться дальше. Гром гремит — это Перун-громовержец злится; кто-то заболел — это Бог его наказывает, вот тебе объяснения, отстань, не задавай вопросов, а лучше помолись.
Современные мифы более глубоки и обычно связаны с наукой. Причины понятна — наука развилась (особенно в последнее время) до такой степени, что часто нужен колоссальный объем знаний, чтобы просто понять, о чем вообще идет речь. У многих людей этого объема нет или безвозвратно потерян, что и снижает их сопротивляемость к разного рода мифам нашего времени. Миф про вредность пищевых добавок Exxx; миф про полезность натурального и вредность «химии»; миф про врачей-убийц, травящих людей прививками; миф про настолько страшное ГМО, что наклейки с надписью «без ГМО» надо клеить даже на салфетки и на пачки с солью.

Что такое ГМО? Зачем они нужны? Как велика опасность и польза от их использования? Есть ли доказательства безопасности этих организмов?

Эрнс Шталингер написал это письмо 6 мая 1970 года сестре Мэри Джаканд, монахине, которая работала среди голодающих детей города Кабве в африканской стране Замбии, в ответ на вопрос о значении освоения космоса. В то время доктор Шталингер был заместителем директора по науке в Центре Космических Полетов Маршалла, в Хэнтсвилле, штата Алабама. Тронутый искренностью и обеспокоенностью Мэри, он направил ей все свои искренние убеждения о ценности исследований космоса. Красноречивое заявление доктора актуально до сих пор, даже спустя четыре десятилетия. Родившись в Германии в 1913 году, доктор Шталингер получил Ph.D. по физике в университете Tuebingen 1936 году. Он был членом немецкой ракетной группы, в Peenemunde и приехал в Соединенные Штаты в 1946 работать на американскую армию в Форт Блисс, штат Техас. Он переехал в Хэнтсвилль в 1950 и продолжил работать для армейского Redstone Arsenal до тех пор пока не был создан центр космических полетов в 1960. Доктор Шталингер был неоднократно награжден и широко известен за свои исследования силовых установок. Он получил награду от министра обороны (Exceptional Civilian Service Award) за участие в запуске Эксплорера-1, первого американского космического спутника.

[Автор этой статьи — Джеф Этвуд (Jeff Atwood), один из основателей stackoverflow.com. Сама же статья, несмотря на довольно приличный возраст (она написана в 2007 году) до сих пор популярна, а введенный в ней термин «FizzBuzz question» стал общеупотребительным. Оригинал можно найти здесь.]

Я весьма скептически отнесся к следующему наблюдению Реджинальда Брейтвайта (Reginald Braithwaite):

«Меня немного удручает тот факт, что 199 из 200 соискателей программистских вакансий не умеют программировать. Повторю: они не умеют писать код. Вообще.»

У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

Известно, что при работе за компьютером мозг программиста затрачивает больше энергии, чем мозг других людей. Программист, как работник умственного труда, должен следить за своим питанием и здоровьем, чтобы поддерживать свой мозг в состоянии высокой работоспособности. К тому же, программист должен быть в отличной интеллектуальной форме, развивать в себе высокую творческую активность и задумываться о предотвращении возрастных ухудшений памяти.

В ранней юности, когда, погружаясь глубоко в проект, я часто забывал о еде и бывало, что моей единственной пищей за день был батон с кефиром. Теперь с годами я понимаю, как тогда травмировал мозг, не давая ему нужные для работы вещества и энергию.

В данной публикации мы рассмотрим, как правильно питаться для жизнеобеспечения мозга и как его разогнать ноотропами (в случае аврала необходимости).

Друзья, рады представить статью из цикла «Войти в IT», который уже давно публикуется в нашем корпоративном блоге. Это не «серьезные» технические статьи (такие тоже будут), а рассказы наших синьоров об их становлении в IT. Ведь иногда хочется просто взглянуть на индустрию глазами коллег и понять, как именно из молодых практикантов и «зеленых» джуниоров получаются эксперты мирового уровня. Что ж, дадим слово одному из наших героев.



Всем привет! Меня зовут Родион Горковенко, и я… нет, не то, о чем вы подумали. Я — Senior Java Developer в компании DataArt. Хочу поделиться историей, как я дошел до жизни такой и, возможно, немного подсказать молодым специалистам, как выжить в беспощадных джунглях Java и стать полноценным цифровым хищником.

Введение (красивая заставка)

Сначала я программировал на C. Были и другие языки, но большую часть времени (несколько лет) я писал именно на C. Поэтому и моя карьера в IT началась с этого языка. Однако область применения его ограничена сравнительно низкоуровневым софтом — я писал на нtv для микроконтроллеров, когда разрабатывал электронику, и позже — для POS-терминалов.

Ответ на вопрос «куда двигаться дальше?» был для меня не очень ясен. Можно, конечно, было углублять изучение C++, но небольшой опыт работы в команде на C/C++ оставил несколько негативное впечатление. Альтернативой была Java. О ней я не знал почти ничего, разве что, пару тестовых приложений для мобильников с JavaME написал еще в институте — конечно, не разбираясь подробно в нюансах языка.

Что ж, в течение года посвященного POS-терминалам, у меня было немного свободного времени до и после работы. Гугление подсказало, что нужно скачать Java Development Kit (JDK) с сайта Sun (теперь java.oracle.com) и, в общем, можно начинать.

Ключевые причины, по которым сотрудники решают сменить место работы – неудовлетворенность заработной платой, невозможность карьерного роста, отсутствие интереса, понимание, что в другом месте, они смогут больше и лучше.

Эта статья входит в серию статей по улучшению производительности в .NET. Первую статью можно найти здесь.

В этой статье, как и в прошлой, будут рассмотрены неочевидные особенности в работе платформы, и приемы, с помощью которых можно с этими особенностями мирно сосуществовать. Проще говоря, тут будут записаны очередные всякие хаки из жизни нашей лавки, которые хоть немного (или много, как всегда все зависит от контекста), но экономят драгоценные ресурсы в условиях высокой нагрузки. Хаки предельно просты и не влияют на конечную функциональность.

Открывая очередную статью о производительности, пожалуй каждый резонно ищет ответ на вопросы «а как это может помочь в моих проектах» и «бросать ли все и начинать ли срочно исправлять свой код как описано». Исправлю ошибку прошлой статьи, отвечу сразу и подробнее. На мой взгляд, есть смысл использовать наши хаки в следующих случаях:

• Вы пишете новый код и решили делать это немного лучше и с экономией
• Вы дошли до этапа, когда начались оптимизации и рефакторинг, поэтому просматриваете и меняете участки кода, которые выполняются очень часто
• Вы пишете высокопроизводительную систему и экономите на спичках

Я ни в коем случае не призываю вас бежать и исправлять весь код в ваших проектах. Более того, я призываю вас не делать этого, потому что это простые хаки, и скорее всего они будут вноситься бездумно в большое количество кода, а это может повлечь за собой появление новых ошибок. Это не те хаки, которые скинут бабу с воза вашего приложения и заставят кобылу-сервак бежать в десять раз быстрее. В лучшем случае удастся выжать процентов десять. Но с миру по нитке — голому рубашка.