Всем привет!

Сегодня мы провели довольно важные изменения на сайте, в результате которых карма многих пользователей была обнулена.
Don’t panic, разъяснения под катом.

Личные фото некоторых знаменитостей, включая Дженнифер Лоуренс, Кейт Аптон и Ариана Гранде были опубликованы анонимным хакером на сайте 4Chan. Судя по всему, утечки стали возможными благодаря взлому аккаунтов от облачного хранилища Apple iCloud, в которое автоматически копируется информация со всех устройств Apple, о чем большинство пользователей даже не задумываются.

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

Пресс-секретарь Дженнифер Лоуренс сделал заявление, подтверждающее, что фотографии являются подлинными:

(пятница)

Обычно развернутое приложение в файловой системе выглядит как-то так:



Совершенно незащищенное от инструментов типа рефлектора или IlSpy, но что если оно станет таким:



По крайней мере легкий ступор хакеру-неофиту обеспечен. Приятно смотрится, и антивирусы не заинтересуются.

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

Что первично в кино — сюжет или игра актёров? Спецэффекты или мастерство оператора-постановщика? Безусловно, все эти составляющие крайне важны. Но, всё же, некоторые фильмы стали знамениты именно благодаря использованным спецэффектам. И пусть сегодня некоторые из них выглядят обыденно, а некоторые наивно, в своё время они стали вехами в кинематографе. Конечно, вообще таких фильмов было много. Но мало кто может похвастаться спецэффектами, исключительно благодаря которым стало возможно рассказать задуманную историю. Такими спецэффектами, которые не просто вызывали вау-эффект, а действительно брали за душу. Которые заставляли сопереживать главному герою, проникаться ситуациями, в которых он оказывался. Давайте вспомним о некоторых из таких знаковых фильмов.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

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

Например, рассмотрим персональное банковское приложение. Пользователь может получить доступ к множеству функций, таких как передача денег между учетными записями, оплата счетов, и обновление персональных данных, используя единственный пользовательский интерфейс (UI). Однако, каждая из этих функций инкапсулируется в пределах дискретного модуля. Эти модули связываются друг с другом и с системами бэкэнда, такими как серверы баз данных и веб-сервисы. Прикладные службы интегрируют различные компоненты в пределах каждого из различных модулей и обрабатывают взаимодействие с пользователем. Пользователь видит интегрированное представление, которое похоже на единственное цельное приложение.

Следующая иллюстрация показывает проект модульного приложения.

C#.NET предлагает множество способов сравнить объекты, как экземпляры классов, так и структур. Способов так много, что без упорядочения этих способов и понимания их грамотного использования и имплементации (при наличии возможности переопределения), в голове, неминуемо, образуется каша.

Введение

В этой статье я хочу рассказать об использовании некоторых конструкций, применяющихся для осуществления неблокирующей синхронизации. Речь пойдёт о ключевом слове volatile, функциях VolatileRead, VolatileWrite и MemoryBarrier. Мы рассмотрим, какие проблемы вынуждают нас воспользоваться этими языковыми конструкциями и варианты их решения. При обсуждении барьеров памяти вкратце рассмотрим модель памяти .NET.

Привет!
Всё просто. Вы берёте и пишете, кто вы, что делаете, и оставляете ссылку на свой профиль. Или на свой проект.

Причин две:

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

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

Если коротко, то «потому что могут». И т.к. стек «дёшев» мы располагаем их на стеке, когда только это возможно.

Длинный ответ он … длинный.

Какое-то время назад я писал о том, что «ссылки» — это не «адреса», когда речь идёт о C# и размещении его объектов в памяти. Хотя это действительно так, но это всего лишь деталь реализации, но не смысл «ссылки». Другая деталь реализации, которую часто путают с сутью — это то, что «память под значимые типы (value types) выделяется на стеке». Я часто это вижу, потому что именно так написано в нашей документации.

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

Введение

Строковый тип данных является одним из фундаментальных типов, наряду с числовыми (int, long, double) и логическим (bool). Тяжело себе представить хоть, сколько либо полезную программу, не использующую данный тип.

На платформе .NET строковый тип представлен в виде неизменяемого класса String. Кроме того, он является сильно интегрированным в общеязыковую среду CLR, а так же имеет поддержку со стороны компилятора языка C#.

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

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

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

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

**Многие слышали о Кевине Митнике – иконе хакерского сообщества, но мало кто знает, что у крэкерского мира тоже есть своя икона – tHE kEYBOARD cAPER. Эта статья описывает период, когда его команда доминировала над всей cracking-сценой.

1. Детство
2. Первый ПК и первая BBS
3. Wolfenstein BBS и первый конфликт
4. Windows эра и первый рейд
5. Создание Phrozen Crew и Интернет
6. Самая большая команда в мире
7. Болезнь
8. Возвращение на сцену
9. Внезапная Смерть и CIA
10. Безработный
11. Эпилог
12. Послесловие переводчика

Детство

Я родился в Южной Африке, до сих пор здесь. Белый, 45+ лет (на данный момент — здесь и далее прим. Manny Calavera). Извините, я не скажу вам дату рождения или своё настоящее имя, но факт в том, что меня зовут tKC. :-) И да, я глухой и рос в школе для глухих детей, пока не попал в обычную в возрасте 13-ти лет, потому что моя речь была хорошо развита и моё состояние было немного «лучше», чем требовалось для специальных школ. Я не говорю со своими родителями на языке жестов, собственно, именно по этому я и общаюсь лучше остальных глухих, если вы понимаете о чём я. А еще я не говорю по-английски, потому что я вырос в среде, говорящей на Afrikaans, где читал по губам.

В предыдущей статье по управленческим инструментам мы разбирали алгоритм, как конструктивно решать проблемы с людьми. Настала очередь поговорить о неконструктивных приемах. И начну с истории.

В 2004 году наш коллектив, мирно делающий проекты для Sun Microsystems, решила приобрести корпорация, мировой лидер по производству микропроцессоров. Прилетел вице-президент корпорации и начал раздавать оферы.

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

И вот иду я по коридору со счастливой улыбкой на лице. Навстречу — директор одного из Sun'овских подразделений, назовем его Сергей. У нас были такие приятельские отношения, поэтому ничто не предвещало беды.

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

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

Сегодня мы завершаем новогоднюю серию постов, посвященных лекциям Школы анализа данных. Последний по порядку, но никак не по важности курс — «Алгоритмы и структуры данных поиска».

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

Мы учли то, о чём нас просили в комментариях к прошлым курсам — теперь при желании можно не только смотреть/скачивать лекции по отдельности, но и загрузить всё разом в виде открытой папки на Яндекс.Диске. Кстати — в предыдущих постах тоже появились такие же апдейты (вот ссылки для удобства: «машинное обучение», «дискретный анализ и теория вероятностей», «параллельные и распределённые вычисления»).



Лекции читает Максим Александрович Бабенко, заместитель директора отделения computer science, ассистент кафедры математической логики и теории алгоритмов механико-математического факультета МГУ им. М. В. Ломоносова, кандидат физико-математических наук.

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

Введение

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

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

В этой статье мы коротко пройдемся по особенностям foreach. Первый момент вы скорее всего знаете, второй момент вы скорее всего не знаете.

Предыдущая статья об Array