Доброго времени суток. Решил поделиться опытом в организации рабочего процесса разработки веб-проектов и не только веб. Расскажу свое видение максимально удобного использования связки типа: bugtraker + git + ci + deploy.



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

Навеяно публикацией «Github опять заблокирован».

Новость о блокировке гитхаба заставила задуматься об изготовлении костылей.

Почему-то сразу пришла в голову мысль об I2P.

И это действительно оказалось несложно.

Предлагаю использовать Tor для доступа к сайтам, к которым отсутствует прямой доступ.

Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.

Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.

Здесь я собираюсь осветить следующие вопросы:

• Внутреннее свойство логгера и примеры софта который его использует.
• Объемы, уровни и детализация сообщений лога.
• Общие правила конфигурации в разработке, в бою и в расследовании.

Библиотека log4net известна и в представлении не нуждается. В ней есть практически всё, что нужно, «из коробки». Однако, есть специфические ситуации, в которых необходимо добавлять/расширять функциональность библиотеки. Конкретная ситуация: есть некоторая библиотека, которая выполняет логирование через log4net в некоторый логер (или несколько — не суть). Эта библиотека используется в N службах. Как сделать так, чтобы логирование происходило в единственный файл? Под катом объяснение, почему FileAppender+MinimalLock не подходит, и реализация Appender'а, который решает задачу. Отдельно хочу сказать, что вопрос о логировании в БД, по сети и т.п. в статье не рассматривается, т.к. это гораздо более серьёзная задача, которая (особенно для больших систем) требует длительного обдумывания и внедрения.

Хочу поделиться с уважаемой публикой.

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

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

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

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

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

Подобную энциклопедию можно очень легко создать средствами других фреймворков и CMS, но я попробую использовать микрофреймворк Slim. Почему? Всё очень просто: настоящая заметка рассчитана на начинающего программиста, который хочет начать изучение Slim Framework.

Под впечатлением статьи 5 Easy Ways to Get Started with PHP on Vagrant хочу поделиться своим способом использования Vagrant для PHP-проекта.

Чего хотелось достигнуть:

• На машине разработчика устанавливаются только Vagrant и VirtualBox;
• Настройки виртуальной машины хранятся в репозитории проекта, позволяя разработчику быстро её разворачивать, а также гибко настраивать под нужды проекта и делиться этими настройками с членами команды;

Этих целей удалось достигнуть с помощью Chef-Solo. Получилась некая заготовка как для создания новых проектов на её основе, так и для интеграции в неё уже существующих проектов: vagrant-php.

Большинство моих профессиональных Java проектов за последнее десятилетие были основаны на Spring или JEE. Обе платформы развиваются достаточно уверенно, однако все ещё страдают от различных проблем.

Spring и JEE по-прежнему остаются золотыми стандартами для масштабных Java-проектов и больших команд разработчиков, трудящихся над сложными enterprise-решениями. Однако, неизбежным следствием зрелости Java-сообщества стала частичная потеря прежнего энтузиазма и инновационности, что существенно ударило по авторитету обоих.

Наткнулся однажды на этот пост и мне подумалось — раз у нас есть такая прекрасная, полностью открытая галерея частных данных (Radikal.ru), не попытаться ли извлечь из нее эти данные в удобном для обработки виде? То есть:

• Скачать картинки;
• Распознать текст на них;
• Выделить из этого текста полезную информацию и классифицировать ее для дальнейшего анализа.

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

Оглавление

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

Навигация на основе представлений (View-Based Navigation)

Несмотря на то, что навигация на основе состояний может быть полезна в сценариях, описанных ранее, тем не менее, навигация в приложении часто требует замены одного представления на другое. В Prism, такой вид навигации называется «навигация на основе представлений (view-based navigation)».

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

• Цель навигации — контейнер для добавляемых, или удаляемых представлений — может обрабатывать навигацию разными способами при добавлении и удалении представлений, или может визуализировать процесс навигации по-разному. Во многих случаях, целью навигации является обычный Frame, или ContentControl, и представления просто отображаются внутри этих элементов управления. Однако существует множество сценариев, когда целью навигации является другой вид элементов управления, таких как TabControl, или ListBox. В таких случаях, навигация может потребовать активации или выделения уже существующего представления, или добавление нового представления.
• Приложению часто будет требоваться, каким-либо образом идентифицировать представление, к которому должна быть выполнена навигация. Для примера, в web-приложениях, страница, к которой выполняется навигация, напрямую идентифицируется по URI. В клиентских приложениях, представление может быть идентифицировано по имени его типа, по расположению файла ресурсов, или множеством других способов. В составных приложениях, состоящих из слабо связанных модулей, представления зачастую определены в раздельных модулях. Отдельные представления, в таких случаях, должны иметь возможность быть идентифицированы без создания дополнительных зависимостей между модулями.
• После идентификации представления, процесс его создания и инициализации должен быть тщательно скоординирован. Это особенно важно при использовании паттерна MVVM. В таком случае, представления и соответствующая модель представления должны быть созданы и ассоциированы друг с другом во время совершения навигации. В случае использования контейнера внедрения зависимостей, такого как Unity, или MEF, при создании модели представления и/или представления может потребоваться использование особого механизма конструирования.
• MVVM паттерн позволяет отделить UI приложения от его логики взаимодействия с пользователем и бизнес-логики. Однако процесс навигации может охватывать как UI, так и логику приложения. Пользователь может начать навигацию внутри представления, в результате чего представление будет обновлено. Но часто будет требоваться возможность инициировать и скоординировать навигацию из модели представления. Важным аспектом для рассмотрения, является способность чётко разделить навигационное поведение между представлением и моделью представления.
• Приложению часто может потребоваться передавать параметры, или контекст, представлению для его корректной инициализации. Для примера, если пользователь производит навигацию к представлению для редактирования информации о выбранном клиенте, ID этого клиента, или его данные, должны быть переданы в представление, для отображения в нем корректной информации.
• Многим приложениям необходимо тщательно координировать навигацию для уверенности, что будут выполнены определённые бизнес-требования. К примеру, пользователю может быть показано всплывающее сообщение о некорректности введённых им данных, во время попытки навигации к другому представлению. Этот процесс требует координации между предыдущим и новым представлениями.
• Наконец, большинство современных приложений позволяют пользователю производить навигацию к предыдущему, или к следующему представлению. Аналогично, некоторые приложения реализуют свой рабочий процесс, используя последовательность представлений, или форм и позволяют пользователю производить по ним навигацию вперёд или назад, добавляя или редактируя данные, перед тем, как завершить задачу и отправить все сделанные изменения одним пакетом. Такие сценарии требуют некоторого механизма журналирования, для того, чтобы последовательность навигации могла быть сохранена, повторена, или предопределена.

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

Неделя Хэллоуина – популяция статей про веб-сайты в облаке Microsoft Azure удваивается.

Как многие знают, на Microsoft Azure есть очень простой сервис для размещения веб-сайтов на .NET, Java, PHP, Python, Node.js. Эту статью можно использовать в качестве шпаргалки для того, чтобы постоянно иметь под рукой перечень опций развертывания и ссылок на инструкции.
В шпаргалке: Visual Studio, Git, Mercurial, TFS, WebMatrix, MSBuild и WebDeploy.

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

Создадим класс под названием “Peer” далее подключим пространства имен “SetNet“ и унаследуем класс “Peer” от базового класса “PeerBase“. Класс должен иметь следующий вид:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using SetNet;
using SetNet;
 
namespace Server
{
    class Peer:PeerBase
    {
 
    }
}

25 октября прошла вторая саратовская конференция веб-разработчиков Wake Up Province, где мне посчастливилось выступить докладчиком. Сегодня же я решил поведать хабрасообществу о своем докладе на ней — думаю, кому-то это может быть интересно. Тема, в общем-то, проста и неказиста: Почему компьютеры причиняют страдания и как объяснить это заказчику. Способы проектирования интерфейсов и принципы «прозрачной» разработки.

Доклад основан на собственном опыте применения в реальной разработке мыслей и выводов одного очень известного человека — Алана Купера. При этом многие наработки «взращены» мною самим, а некоторые — заимствованы с Хабра.

Под катом несколько облагороженный текст доклада и почти полтора десятка слайдов (~660Kb). Дабы не разрывать текст, слайды спрятаны в спойлеры.

Привет, Хабрахабр!

Около года назад я написал свой предыдущий пост на Хабре Amazon глазами инсайдера. Я трижды проходил практику в компании Амазон и, тут нечего скрывать, привязался к этой компании, принял многие ее принципы, и многому научился. Причем увидел я компанию с разных сторон, так как довелось поработать и в Amazon Retail и в Kindle, и в Сиэтле и в Калифорнии. Однако моей целью, начиная со второго курса, была практика в Гугле. Поэтому, когда меня наконец пригласили на интервью, и по его результатам позвали в Mountain View на практику в качестве Software Engineer, отказаться я не смел. Провел я там три месяца, работая в команде Gmail Spam & Abuse. Поневоле и бессознательно, я сравнивал жизнь и работу в Гугле с Амазоном, о чем и хочу поделиться.

Дисклеймер: в предыдущей статье я рассказывал обо всем как есть без сравнений. Это отчасти потому, что про внутреннюю культуру Амазон мало что известно. Про Гугл же, напротив, знают все. Рассказать о Гугле «с чистого листа» не получится. Поэтому здесь приведены мои сугубо личные наблюдения и сравнения. Надеюсь, ничьих чувств не задену.

Сегодня существует большое количество DC-клиентов на самый разный вкус. Однако все они наделены существенным недостатком: нужно ждать, пока скачиваемый файл полностью загрузится. А если вы желаете посмотреть фильм или новый эпизод любимого сериала в высоком качестве, то даже при скорости интернета 100 Мбит/с ждать придется довольно долго. Но ведь хочется-то сейчас!

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


Лишь одно из этих погодных приложений пытается решить насущную проблему.

В сообществе дизайнеров наблюдаются расходящиеся тенденции. С одной стороны мы наблюдаем интересные блоги от Райана Сингера и Джулии Жуо, которые развивают наше ремесло. С другой стороны, всё большее количество народу постят свои работы и обсуждают их на Dribbble, что в целом двигает наше ремесло в обратную сторону. Этот пост – не про Dribbble, как таковой, он про то, что ценит это сообщество. Я буду использовать термин «дизайн продукта», но также буду иметь в виду дизайн пользовательских взаимодействий с продуктом.

О чем

Этой темой я хочу открыть серию статей о личных финансах, в которых я постараюсь вкратце изложить суть персональных финансов и личного финансового планирования, исходя из своего практического опыта, а также знаний, которые были почерпнуты (и отфильтрованы) из книг и семинаров. Хочу поделиться этим, потому что «деньги любят счет», а мы об этом часто забываем, что, в последствии, вылезет нам боком. Персональные финансы — это не только учет доходов и расходов в Excel или на смартфоне, это достижение жизненных целей более кратким и, возможно, единственно правильным путем. Эта тема не о том, как и куда инвестировать! Я наоборот вас отговорю делать многие глупые вещи, потому что сам конкретно влип в свое время. Эта тема о том, как сохранить и приумножить безопасно. Самое интересное — все довольно легко, не требует ущемления себя в чем-то — вы живете так же, как и жили. Но при этом достигаете большего.

Почему

Информации на эту тему просто невероятно много. Почти каждый день нам предлагают «сохранить и приумножить» наши сбережения с помощью Forex, фондового рынка, недвижимости и земли, банковских и страховых продуктов и т. д. В этой статье я опишу главные моменты — с чего стоит начать. Если попытаться охватить всю тему — читать можно будет очень долго. Нужно с чего-то начать, сделать первый шаг. Как это не покажется странным, но я свой первый шаг сделал всего три года назад (о чем ни капли не жалею — результат приятно удивляет), причем «в теории» знал о том, что его нужно сделать еще в 2004 году. Тяжело объяснить, зачем это нужно, пока сам не попробуешь. Я рассказываю своим друзьям, чего я добился всего за три года правильного планирования — и они просят помочь им сделать то же самое. Потому что мой результат «можно потрогать» — лежит на счетах в банках.

Откуда мне знать

Стоит, наверное, вкратце рассказать о своем опыте, кому будет интересно — опишу детальнее как-то всю историю. В 2003 прочитал уже всем надоевшего Киосаки. С этого момента меня прорвало, я захотел, как он стал интересоваться персональными финансами и инвестированием. За эти 10 лет я успел заработать и потерять деньги (в основном потерять и ОЧЕНЬ много, потому что основные движения пришли в 2007-2008, когда терять начали даже самые умные эХсперты, не говоря уже о простых людях ) на следующих инструментах: банки, кредитные союзы, фондовый рынок, Forex, земля, недвижимость, валютные операции — это, что вспомнил. Только года три назад пришло наконец «осознание» и я начал делать адекватные вещи в этом направлении. До этого действия предпринимались на основе теорий и мыслей/советов других людей. Кризис научил думать своей головой и я ни о чем не жалею.

В этой статье мы продолжаем наше знакомство со структурой и основными функциональными элементами пакетной сети оператора мобильной связи, которые мы начали в предыдущих двух статьях — GPRS изнутри. Часть 1 и GPRS изнутри. Часть 2. В нашей сегодняшней заметке речь пойдет об основных интерфейсах сетевых элементов PS Core Network, а также стеках проколов, используемых на этих интерфейсах.

Речь в данной статье пойдет о том, как автоматически получать свежую версию исходников из основной ветки вашего репозитория и разворачивать из нее проект на виртуальном хостинге. Сразу хочу отметить, что с GitHub'ом и Git'ом я познакомился только вчера. Поэтому матерым веб–программистам эта статья может показаться тривиальной. А тем, кто еще только начинает свой путь веб–программиста, надеюсь, поможет.