Привет хабралюди.

Не так давно я заинтересовался одним из многочисленных ныне языков под JVM — Scala. Причин тому много, основная — всё нарастающее со временем чувство неудобства при работе с cpp-подобными языками. Взгляд мой попеременно падал на Ruby, Groovy, Python, но все они оставляли впечатление инструментов, не совсем подходящих для моего обычного круга рабочих задач (Python-таки хорош, но у нетипизированных языков есть свои ограничения). Scala же, напротив, показалась вполне годным языком. Так как поиск по хабру никаких статей о ней не выловил (было несколько, но мягко говоря не вводных), я решил написать маленький обзор и поделиться им с массами.

Поговорим о рисках

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

GWT 2.0 официально доступен для загрузки. Новая версия содержит множество нововведений.
Кратко все эти возможности описаны в видео:

Плазмоид (plasmoid) — это виджет рабочего стола в KDE4 Desktop. Любой видимый элемент управления на рабочем столе является плазмоидом, будь то часы, системный трей, монитор загруженности процессора или окошко с прогнозом погоды.

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

По просьбам хабраюзеров я сделал перевод текста, составленного abchernin на основе PEP 8 — «Styleguide for Python Code» (см. топик).

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

Надеюсь, вам будет полезна моя работа: pdf, 200кб

Вслед за первой частью, призванной в первую очередь показать, что «не так страшен чёрт, как его малюют»

Статья об архитектуре части проекта, которая занимается он-лайн платежами. Намеренно не хотелось бы сейчас подробно описывать API конкретного биллинга или процедуру регистрации в нём. Тонкости конкретных биллингов нужно обсуждать отдельно, иначе тему просто не раскрыть. Цель статьи: обсудить вариант архитектуры, позволяющий нанизывать новые виды биллингов и типы платежей, с наименьшей головной болью.

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

Для того чтобы познакомиться с механизмом хуков в git, достаточно просто начать их использовать и посмотреть как оно работает, и как оно устроено внутри.
Хуки в git это некие скрипты, срабатывающие на определенные события, по сути своей являются их обработчиками. Расположены они в каталоге .git/hooks.

Не так давно мы анонсировали на Хабре проект UniverTV, который был отлично воспринят Хабрособществом. Однако, было множество комментариев об отсутствии на сайте раздела «Информационные технологии»…

Представлю вам последнее видео, посвященное языку программирования Scheme. Дальше мы переходим на Пролог, а напоследок постараемся реализовать классы в функциональном языке.


Если не доступен режим HD, то перейдите, пожалуйста, на vimeo.

Полное решение третьего задание по курсу Programming Paradigms, включающее набранный в видео код.

Видео доступно:

• На Vimeo
• На YouTube (часть 1, часть 2)
• На rpod.ru

Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

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

У моего проекта несколько зависимостей. Бóльшая часть зависимостей живет в гитовых репозиториях. Сам проект тоже живёт в гите.

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

Раньше я просто копировал зависимости в папку проекта, и добавлял к каждой файл VERSION.TXT с её версией. Но, если нужно работать с текущей версией стороннего кода, это неудобно. Да и копировать файлы руками когда есть гит как-то глупо. Хочется найти более современное решение.

Задача

Lua — язык с динамической типизацией.

Это значит, что тип в языке связан не с переменной, а с её значением:

a = "the meaning of life" --> была строка,<br/>
a = 42                    --> стало число

Это удобно.

Однако, нередко встречаются случаи, когда хочется жёстко контролировать тип переменной. Самый частый такой случай — проверка аргументов функций.

Рассмотрим наивный пример:

function repeater(n, message)<br/>
  for i = 1, n do<br/>
    print(message)<br/>
  end<br/>
end<br/>
 <br/>
repeater(3, "foo") --> foo<br/>
                   --> foo<br/>
                   --> foo

Если перепутать местами аргументы функции repeat, получим ошибку времени выполнения:

> repeater("foo", 3)
stdin:2: 'for' limit must be a number
stack traceback:
	stdin:2: in function 'repeater'
	stdin:1: in main chunk
	[C]: ?

«Какой такой for?!» — скажет пользователь нашей функции, увидев это сообщение об ошибке.

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

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

Добро пожаловать!

    В прошлый раз мы обсуждали, как можно писать свое PyQt4-приложение, опираясь на логику сгенерированного программкой pyuic4 файла. Как это часто бывает — после написания топик получил много интересных и, что самое главное, содержательных комментариев, объясняющих, почему в отдельных случаях я прав, а в других неправ.
    Самое любопытное состоит еще и в том, что обсуждение интересно как для питонистов, так и для приверженцев C++, ибо в данном случае разница невелика, в основном только незначительные вещи в синтаксисе. Все это потому, что PyQt4, по своей сути, является простой оберткой вокруг сишных Qt-классов, сохраняющей все названия и методы. Итак, вот вам чашечка чая или кофе, устраивайтесь поудобнее, давайте начнем нашу беседу.

Часть 2

Добрый вечер/день/утро уважаемые хабралюди! Продолжаем развивать и дополнять блог о моей любимой open source rdbms Postgresql. Чудесным образом так получилось, что тема сегодняшнего топика еще ни разу здесь не подымалась. Надо сказать, что секционирование в postgresql очень хорошо описано в документации, но разве ж это меня остановит?).

На блоге несколько постов назад мы собирали вопросы к подкасту по тестированию. На прошлой неделе мы его записали :-)
Участники:
Асхат Уразбаев – ScrumTrek
Илья Гаврилов – начальник отдела тестирования, Exigen
Алексей Лупан – testitquickly.com
Темы

• Как вы стали тестировщиком?
• Чем программист отличается от тестировщика?
• Какой процент кода покрывать авто-тестами?
• Есть ли вред от TDD?
• Кто пишет и кто запускает тесты?
• Имеет ли смысл иметь выделенного тестировщика-автоматизатора и в каких случаях?
• Как проходит планирование итерации с точки зрения тестировщика?
• Где хранить тесткейсы?
• Как автоматизировать тестирование GUI и что такое архитектура тестирования?
• Рост продуктов – как успевать все протестировать за итерацию?

Аудио

Недавно друг попросил установить ему Windows 7. Так уж вышло, что мой DVD-привод давно не работает, зато есть флешка на 8 ГБ. Тема создания загрузочной флешки с Windows 7 из-под Windows уже давно сильно разжевана в Сети. Но я пользуюсь Ubuntu, так что пришлось искать другое решение. На самом деле, как мне кажется, оно еще и проще.

Многие мои знакомые так или иначе используют протокол SSH (заходя на свои роутеры, веб хостинги и непосредственно на собственные компьютеры дома и в офисе), при этом не все об этом знают.



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

В этой заметке вы узнаете:

• как прописать псевдонимы для соединений
• как настроить авторизацию без пароля
• как передавать файлы по SSH
• как запускать графические приложения по SSH
• а так же получите общие советы по опциям SSHD