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

Разработчики ASP.NET получили уникальный инструмент, который может облегчить их жизнь. Проект с открытыми исходными кодами Glimpse созданный энтузиастом веб-разработки предлагает то, что можно назвать серверным вариантом популярного средства отладки firebug (расширение для Firefox).

Glimpse – это расширение, которое можно добавить в проект на базе ASP.NET и получить богатую отладочную серверную информацию во время работы веб-приложения.



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

• конфигурация веб-приложения;
• значение переменных окружения и информация о .NET-сборках;
• информация о этапах выполнения жизненного цикла приложения в ответ на запрос;
• информация о используемых маршрутах ASP.NET при работе приложения;
• параметры HTTP-запросов;
• параметры сессий ASP.NET  и значения сохраненные в них;
• параметры и жизненный цикл представлений ASP.NET;
• отслеживание и работа с Ajax-запросами.

Как и многие инструменты сегодня, Glimpse доступен для легкой автоматической установки через пакетный менеджер NuGet. Рассмотрим подробно процесс установки и использования.

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

Вы читаете вторую часть:

• Создание простейшего решения (solution) со стандартными конечными точками (default endpoints)
• Добавление и настройка конечных точек вручную

Предыдущая часть описывала простейший пример создания службы (service) WCF и её вызова из клиентского приложения. В этой части вы сможете узнать, как можно достичь точно такого же результата, но теперь мы будем настраивать всё вручную. Таким образом, мы переопределим (override) стандартные конечные точки, настроим наши собственные, и в итоге получим точно такое же поведение нашего приложения.

Давайте придумаем аналогию, а затем хорошенько над ней поиздеваемся: представьте, что вы только что приобрели земельный надел. Чем вы будете заниматься? Добычей ископаемых или фермерством?

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

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

Вас ожидают две части:

• Создание простейшего решения (solution) со стандартными конечными точками (default endpoints)
• Добавление и настройка конечных точек вручную

Прошло много времени с тех пор, как я написал оригинальный пост Простой пример использования WCF. Это было еще до выхода Visual Studio 2008, и с тех пор многое изменилось. Поскольку множество людей по-прежнему задают вопросы в комментариях к тому посту, давайте посмотрим, что в настоящее время мы должны сделать, чтобы поднять и запустить службу (service), а также обратиться к ней из клиентского приложения.

Современная сеть воспитывает в нас свободу слова, а точнее, возможность свободно сказать что ты хочешь, не неся за это ответ. Принято считать, что найти сетевого человека в реале проблематично, тем более он принял меры для своей анонимности, и что только спец. службы по IP могут определить ФИО и паспортные данные ;) Все мы бывали в ситуациях, либо наблюдали их, либо хотя бы слышали, как кто-то кого-то в сети шлёт на 3 буквы, в ответ ему обещают вычислить IP и найти его, переломать ноги итп.

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

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

Давайте попробуем разобрать несколько конкретных примеров и попробуем поразмышлять на тему анонимности в сети.

Договоры, отчеты, акты — кому охота заниматься этой скукотой, когда вокруг бьет ключом и фонтанирует идеями креативная жизнь? Особенно, если заказчик снисходительно хлопает творческого подрядчика по плечу: «Да ладно, зачем какие-то договоры. Мое слово — закон!» Остается только радостно согласиться и приступить к работе.

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

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

Оригинальное название статьи: «The * stupidest things I’ve done in my programming job», поэтому перевод названия статьи не очень точен, однако то, что автор имел ввиду под "*" мы опустим — мы ведь не знаем наверняка :)

Я больше не стыжусь своих грешков, так что — вперед:

1. ORM

Глупость

Создал собственную ORM (Object Relational Mapping) библиотеку

Следствие

Неразбериха в проекте после двух лет поддержки, в следствие хаков-обходов моей ORM библиотеки для запуска прямых SQL запросов

Что я должен был сделать

Использовать Hibernate, iBATIS, Cayenne или нечто подобное.

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

Существует два способа обрабатывать параллельные запросы к серверу. Потоковые (threaded, синхронные) серверы используют множество одновременно выполняющихся потоков, каждый из которых обрабатывает один запрос. В это время событийные (evented, асинхронные) серверы выполняют единственной цикл событий, который обрабатывает все запросы.

Чтобы выбрать один из двух подходов, нужно определить профиль нагрузки на сервер.