По мнению некоторых экспертов, к 2025 году беспилотные автомобили полностью войдут в обиход и к 2030-му целиком захватят рынок личного транспорта. Давайте посмотрим, к чему это приведет.

Читая Geektimes, я регулярно нахожу для себя что-то новое и интересное, обращая особое внимание на все, что связано с медициной и здоровьем. Так уж сложилось, что основной интерес у меня в технологичных протезах конечностей — я врач травматолог-ортопед по образованию. По второму образованию я — врач мануальный терапевт. А еще я зануда и люблю разбираться в том, чем занимаюсь. Именно из-за моего профильного образования, занудства, а так же из-за возрастающего интереса аудитории geektimes к корректорам осанки (достаточно часто встречаю статьи на эту тематику) я понял, что мне есть что рассказать, поделиться своим видением коррекции осанки, а так же рассказать, почему корректоры осанки в том виде, в котором они существуют сейчас, будут помогать лишь в очень ограниченном количестве случаев, а в отдельных ситуациях могут и вредить.

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

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

В наши дни, МКЭ — это наверное самый распространенный метод для решения широкого спектра прикладных инженерных задач. Исторически, он появился из механики, однако впоследствии был применен к всевозможным не механическим задачам.

Сегодня имеется большое разнообразие программных пакетов, таких как ANSYS, Abaqus, Patran, Cosmos, и т.д. Эти программные пакеты позволяют решать задачи строительной механики, механики жидкости, термодинамики, электродинамики и многие другие. Сама реализация метода, как правило считается достаточно сложной и объемной.

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

Картинка для привлечения внимания:

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

В этом выпуске серии «5 вещей …», я представлю некоторые из тонких аспектов многопоточного программирования, в том числе synchronized-методы, volatile переменные и атомарные классы. Речь пойдет в особенности о том, как некоторые из этих конструкций взаимодействуют с JVM и Java-компилятором, и как различные взаимодействия могут повлиять на производительность приложений.

Предлагаю читателям «Хабрахабра» перевод публикации «ExecutorService — 10 tips and tricks».



Абстракция ExecutorService была представлена еще в Java 5. На дворе шел 2004 год… На секунду – сейчас Java 5 и 6 больше не поддерживаются и Java 7 готовится пополнить список. А многие Java-программисты по-прежнему не в полной мере понимают как работает ExecutorService. В вашем распоряжении множество источников, но сейчас я хотел бы рассказать о малоизвестных тонкостях и практиках по работе с ней.

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

4 октября — двойной праздник в отечественной и мировой космонавтике. В 1957 году, стартом "Спутника 1" началась космическая эра человечества. Впервые космический аппарат сумел преодолеть гравитацию Земли, и выйти на околоземную орбиту.  В 1959-м стартом "Луны-3" началась эра исследования Солнечной системы. Космический аппарат смог развить вторую космическую скорость, добраться до окрестностей Луны, снять ее обратную сторону и передать изображения на Землю. Так, впервые люди увидели подробности иного космического тела, которые никогда бы не смогли увидеть с Земли.

Мы наблюдаем бум свободных проектов. В основном, благодаря Гитхабу. 23 декабря 2013 года на сервисе был создан 10-миллионный проект. К 23 декабря 2015 года количество проектов более чем утроится: прямо сейчас на Гитхабе 28 миллионов проектов.

Многих привлекает идея свободности, потому что она перекликается с идеей «улучшения мира», как основной мотивации продуктивной деятельности человека.

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

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

Само по себе выкладывание проекта не является улучшением мира

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

Вы выложили код. Чем вы помогли экономике в этот момент? Ничем, поэтому и миру вы пока ничем не помогли.

Ваш проект может спасать людей от рака, быть бесплатным, экономить миллионы долларов, и при этом быть закрытым.

Сконцентрируйтесь не на том, чем вообще полезен ваш проект, а чем полезна его свободность.

Синергетический эффект свободного кода

Коллеги, у меня для вас есть замечательная новость, мы получили чудесный проект, его несколько лет писали неизвестные нам разработчики, адрес которых мы вряд ли узнаем (чтобы «поделиться обратной связью»), писали очень давно и не известно под чем, и нам предстоит его поддерживать и развивать. Проект сейчас находится на пике своей производительности и мы скоро упремся, любые неаккуратные изменения могут его положить, но мы будем его развивать. Ура!

Согласитесь, странно звучит? Как бред больного на голову программиста. Кто же любит legacy? Это же всегда говнокод (ведь только мы сами пишем идеально), в нем полно багов (а мы сами пишем без ошибок), ужасные решения (ведь только мы сами выбираем подходящую архитектуру), и почти всегда его сложно читать (ведь только мы сами пишем понятно и красиво).

Из закона всемирного тяготения известно, что на поверхности тел шарообразной формы ускорение свободного падения постоянно по модулю и направлено к центру шара. Для тел неправильной формы это правило, очевидно, не выполняется. В этой статье я покажу способ расчёта и визуализации ускорения свободного падения для таких тел. Расчёт будем производить на JavaScript, визуализировать — на WebGL с использованием библиотеки three.js.

В итоге получим следующее (красным цветом отмечены области с большим ускорением свободного падения, синим — с малым):

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

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

Если Вы не следите за оставшимся свободным местом в корневом разделе — то Вас могут ожидать неприятные новости. В случае переполнения данного раздела, важные для Вашего проекта сервисы перестанут работать. Согласитесь, неработающий MySQL или web server скажется на проекте не лучшим образом.

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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

С каждым днем слово java все больше и больше воспринимается уже не как язык, а как платформа благодаря небезызвестному invokeDynamic. Именно поэтому сегодня я бы хотел поговорить про виртуальную java машину, а именно — об так называемых Performance опциях в Oracle HotSpot JVM версии 1.6 и выше (server). Потому что сегодня почти не встретить людей, которые знают что-то больше чем -Xmx, -Xms и -Xss. В свое время, когда я начал углубляться в тему, то обнаружил огромное количество интересной информации, которой и хочу поделится. Отправной точкой, понятное дело, послужила официальная документация от Oracle. А дальше — гугл, эксперименты и общение:

-XX:+DoEscapeAnalysis

Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Как многие из Вас знают, примитивы и ссылки на объекты создаются не в куче, а выделяются на стеке потока (256КБ по умолчанию для Hotspot). Вполне очевидно, что язык java не позволяет создавать объекты на стеке на прямую. Но это вполне себе может проделывать Ваша JVM 1.6 начиная с 14 апдейта.

Про то, как работает сам алгоритм можно прочитать тут (PDF). Если коротко, то:

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

Для реализации данного алгоритма строится и используется так называемый — граф связей (connection graph), по которому на этапе анализа (алгоритмов анализа — несколько) осуществляется проход для нахождения пересечений с другими потоками и методами.
Таким образом после прохода графа связей для любого объекта возможно одно из следующих следующих состояний:

• GlobalEscape — объект доступен из других потоков и из других методов, например статическое поле.
• ArgEscape — объект был передан как аргумент или на него есть ссылка из объекта аргумента, но сам он не выходит из области видимости потока в котором был создан.
• NoEscape — объект не покидает область видимости метода и его создание может быть вынесено на стек.

После этапа анализа, уже сама JVM проводит возможную оптимизацию: в случае если объект NoEscape, то он может быть создан на стеке; если объект NoEscape или ArgEscape, то операции синхронизации над ним могут быть удалены.

Следует уточнить, что на стеке создается не сам объект а его поля. Так как JVM заменяет цельный объект на совокупность его полей (спасибо Walrus за уточнение).

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

    for (int i = 0; i < 1000*1000*1000; i++) {
        Foo foo = new Foo();
    }

скорость выполнения может увеличится в 8-15 раз. Хотя, на казалось бы, очевидных случаях из практики о которых недавно писалось (тут и тут) EscapeAnalys не работает. Подозреваю, что это связано с размером стека.

Кстати, EscapeAnalysis как раз частично ответственен за известный спор про StringBuilder и StringBuffer. То есть, если Вы вдруг в методе использовали StringBuffer вместо StringBuilder, то EscapeAnalysis (в случае срабатывания) устранит блокировки для StringBuffer'а, после чего StringBuffer вполне превращается в StringBuilder.