Здравствуйте! В этой статье я вкратце расскажу вам о процессах, потоках, и об основах многопоточного программирования на языке Java.
Наиболее очевидная область применения многопоточности – это программирование интерфейсов. Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации. Например, поток, отвечающий за интерфейс, может ждать завершения другого потока, загружающего файл из интернета, и в это время выводить некоторую анимацию или обновлять прогресс-бар. Кроме того он может остановить поток загружающий файл, если была нажата кнопка «отмена».

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

Давайте начнем. Сначала о процессах.

Добрый день!



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

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

Итак, сначала немного пафоса.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Введение

В настоящий момент сложно себе представить программное обеспечение, работающее в одном потоке. Конечно, существует ряд простых задач, для которых один поток более, чем достаточен. Однако так бывает далеко не всегда и большинство задач средней или высокой сложности так или иначе используют многопоточность. В этой статье я буду говорить об использовании синглтонов в многопоточной среде. Несмотря на кажущуюся простоту эта тема содержит множество нюансов и интересных вопросов, поэтому считаю, что она заслуживает отдельной статьи. Здесь не будет затрагиваться обсуждение того, зачем использовать синглтоны, а также как их правильно использовать. Для прояснения этих вопросов я рекомендую обратиться к моим предыдущим статьям, посвященным разным вопросам, связанным с синглтонами [1], [2], [3]. В этой статье речь будет идти о влиянии многопоточности на реализацию синглтонов и обсуждению вопросов, которые всплывают при разработке.

Автор: Джоэль Спольски. Оригинал.

Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.

Intro

Привет, хабр! Ты наверное знаешь о недавних событиях, которые распиарили по интернету как «взлом» системы in-app покупок apple. Так вот, это было не совсем так. Это даже не было взломом. И ключевые выводы, которые я сделал:

• Закрытость<>Защищенность
• В Apple тоже очень даже ленивые люди работают

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

Технология

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

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

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

И вот несколько вещей, которые вызывают у меня непонимание.

Я уже частично говорил о работе с FITS-файлами в Octave. Теперь расскажу о применении этого математического пакета для обработки конкретных данных, а именно: для вычисления центра вращения звездного поля по набору снимков, полученных с определенным интервалом.

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

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

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

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

Почему Roslyn?

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

Как пишет Soma в своём блоге, часть Visual Studio language team работает на проектом, который называется Roslyn. Его главная цель — переписать компиляторы C# и VB и создать языкове сервисы в управляемом коде. С чистым, современным и управляемым кодом наша команда сможет быть более продуктивной, внедрять инновации быстрее и выдавать больше возможностей скорее и с лучшим качеством.

Более того, мы открываем компиляторы C# и VB со всей их внутренней информацией, делая доступным для вас анализ кода. Мы предоставляем публичное API и обеспечиваем точки расширения в языковых сервисах C# и VB.

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

В первой части серии я начал обсуждение некоторых особенностей функционального программирования, показывая проявления этих идей в Java и других, более функциональных языках. В этой статье я продолжу свой обзор, обращая внимание на функции — объекты первого класса, оптимизации и замыкания. Но основная тема этой статьи — контроль: когда вы его хотите, когда он вам необходим и когда надо просто забить.

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

Эта история может показаться Вам знакомой, поставив функциональное программирование на место бензопилы. Проблема в совершенно новой парадигме программирования — не изучение нового языка. Более того, синтакс языка — это всего лишь детали. Вся тонкость же — научиться мыслить иначе. Это то, почему я оказался тут — заводящий бензопилы и “функциональный” программист.

Итак, добро пожаловать в Functional thinking. Эта серия исследует предмет функционального программирования, но не несет исключительной направленности описать функциональные языки. Как я покажу дальше, написание кода в функциональном стиле касается дизайна, компромиссов, разных повторно используемых кусков кода и служит основой для иных догадок. Насколько это окажется возможным, я попытаюсь показать концепции функционального программирования в Java (или близких к Java языках) и перейду к другим языкам, чтобы осветить возможности, отсутствующие на данный момент в Java. Я не полезу сразу в дебри, рассказывая о довольно необычных вещах, таких как монады (monads). Напротив, я постепенно проведу Вас через новый путь мышления.

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

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

В данной статье будет рассматриваться вызов управляемого C# — кода(.Net) из неуправляемого С — кода.
Как-то раз на работе дали проект, точнее даже не сам проект, а только его часть. Сам же проект состоял из двух частей: функционал, написанный на С (unmanaged code) и интерфейсная часть, написанная на C# (managed code). Моей задачей было написать интерфейс и связать его с функционалом.