(Сокращённый перевод статьи Пьера-Хьюза Шарбонне)

Как уже сообщалось ранее на Java One, в Java 8 версии HotSpot планируется отказаться от PermGen пространства в пользу новой его вариации — Metaspace. Ранний доступ к JDK 8 даёт возможность наблюдать Metaspace в действии, чем и воспользовался автор оригинальной статьи чтоб узнать, какие преимущества даёт MetaSpace в сравнении с PermGen, и убедится во всём непосредственно.

Подробнорсти под катом.

Здравствуй, %USERNAME%!

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

Зачем.

В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад, я попытался собрать все вещи, которые понадобились бы человеку, задумай он «с нуля» написать приложение на RoR. То есть не углубляясь ни в одну из областей, описать необходимый минимум действий, чтобы установить, настроить и написать своё первое приложение.Здесь собрано, как мне кажется, всё, что нужно и я надеюсь этот текст сэкономит кому-нибудь несколько часов поиска в интернете). Сам изучаю RoR вторую неделю, так что не судите строго).

Установка.

Просто и быстро ror ставится через rvm c rvm.io.

>\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enabled

Запустить rvm:

>source /Путь_к_домашней_директории*/.rvm/scripts/rvm

*$HOME в дальнейшем.
После этого в $HOME/.bash_profile должна появиться строчка:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

и при каждом открытии консоли rvm будет подгружаться, но у меня этого не случилось — пришлось ещё в $HOME/bashrc прописывать:

. ~/.bash_profile

Теперь всё точно должно быть хорошо.
Устанавливаем нужную(скорее всего это будет самая последняя) версию руби (сколько их и в чём отличие можно посмотреть здесь -http://www.ruby-lang.org).

>rvm install 1.9.3

Проверка на успешность создания

>ruby -v

должна вернуть более подробную информацию, вроде

ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux].

В процессе установки я случайно установил несколько версий, что потом доставило некоторые неприятности). Посмотреть список установленных версий руби можно так:
>rvm list
Если версий несколько, то текущая будет помечена "=>", дефолтная — "*", а текущая и дефолтная — "=*". Поменять на нужную используемую версию можно так:

>rvm use ruby-1.9.2-p320 (любая нужная версия)

Чтобы поменять дефолтную версию руби пишем:

>rvm use ruby-1.9.2-p320 --default

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Эта поучительная история повествует о том, как важно развивать навыки гугления, и о том, как я боролся с ежечасным полным Garbage collection.

Краткое описание проблемы

После того, как мы мигрировали в продакшене один из компонентов системы (единственный, работающий на Tomcat) на новую версию томката, неожиданно саппорт запаниковал, увидев в логах полуторасекундные запуски GC.

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

CoffeeScript — это маленький язык, который транслируется в JavaScript. Его документация умещается на одной странице — coffeescript.org и отличается компактностью и наглядностью. Я даже сомневался в необходимости данной статьи, когда есть такое классное описание «от производителя», но все же рискнул расставить акценты и прояснить некоторые детали.

Здравствуйте, Хабралюди.

Мал по-малу из моего опыта и наших проектов родилась небольшая библиотека для работы с моделями в джаваскрипте. Она так и называется — Model.js.

Я расскажу вам вкратце об этой библиотеке и этим постом запрашиваю обратную связь у тех, кто создавая сложные джаваскрипт-приложения, уже решает эту проблему каким-то определенным образом без фреймворков. Интересно также и мнение тех, кто только подыскивает подходящий инструмент для своих нужд: какой инструмент вам нужен и насколько вам подходит Model.js?

Продолжая тему веб-разработки мобильных сайтов и приложений под мобильные устройства нельзя не затронуть такую тему как Фреймворки для манипуляции DOM и отправкой асинхронных запросов.
Стандартом на десктопе уже давно стал jQuery, но он никуда не годится для разработки под мобильную платформу. Давайте посмотрим, как jQuery дружит с мобильными устройствами.

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

В целом, это хочется делать просто и понятно. При этом хочется разумного компромиса. Я встречал некоторые библиотеки, которые дают мощный функционал, но при этом по объему — десятки килобайт JavaScript кода. Несколько десятков килобайт, чтобы, например, подменить параметр в QueryString? Эх…

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

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.

Предупрежу заранее, что я совершенно не считаю себя экспертом HTML/CSS/JS. Но, как архитектору, мне всегда была интересна организация и систематизация кода в самых разных его проявлениях, в том числе и представленных в виде CSS. Особенно сильно этот интерес был подогрет БЭМом, при первом знакомстве с которым подсознание отреагировало когнитивным дискомфортом. А поскольку БЭМ-стиль в проектах у меня стал появляться все чаще, я почувствовал острую необходимость осмыслить, наконец, свое отношение к организации стилей. Таким образом и появился данный топик-размышление, топик-дискуссия. Я понимаю, что взялся за пограничную задачу, поскольку далеко не всем верстальщикам знакомы тонкости объектно-ориентированного дизайна, а большинство архитекторов не написали ни одного CSS-стиля. И, как результат, мне пришлось неуклюже балансировать, чтобы было понятно всем. Но 'этот риск еще больше подогрел мой интерес к теме :)

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

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

Когда-то я собрала набор простых правил, которые помогают избежать 80% самых распространенных ошибок, касающихся построения интерфейсов. Решила расшарить их для хабрасообщества.
Кому интересно — добро пожаловать под кат.

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.