Показаны сообщения с ярлыком наблюдения. Показать все сообщения
Показаны сообщения с ярлыком наблюдения. Показать все сообщения

пятница, 3 августа 2012 г.

Миграция на .NET платформу: Начальные сведения о платформе

Чтобы начать хоть что то писать, при переходе с Java, мне потребовалось узнать:

Синтаксис

В большинстве случаев, синтаксис Java и C# похожи. Из незнакомого (и того, что нужно знать "уже сейчас"):
  • out параметры - такого в java нету, а в C# используется довольно часто;
  • Область видимости internal;
  • static class - для любителей "Tools" и "Utils" классов :);
  • виртуальные методы и overriding - это по началу вызвало особые недоумения;
  • индексатор([]) и перегрузка операторов - такого тоже нету в Java, но эти механизмы часто используются;
  • делегаты и events - для меня, это оказались самыми непривычными и непонятными темамию (полезная статья и еще одна);
  • Структуры (structure) - очень похожи на классы, но ведут себя по особенному:) (очень рекомендую почитать).

Коллекции

Структура коллекций и их интерфейсы очень отличается от java collections. Особенно "доставляет" класс Dictionary :) (линк).
Также есть интересная библиотека Power Collections - "типа" commons-collections.

Assembly и зависимости

Принципе, ничего сложного и нового. Просто надо знать что это такое, как его создать и настроить.

Resources (строки, файлы, иконки)

Очень полезная штука. В java вопрос хранения и доступа к внутренним строкам, иконкам и др. файлов решался как попало и чем попало. В .NET у assembly есть контейнер, в котором можно хранить именованные ресурсы. Также есть механизм удобного программного доступа к ним. Особенно это радует при разработке UI модулей и иногда, при написании тестов.

четверг, 2 августа 2012 г.

Миграция на .NET платформу: Базовый инструментарий

Просто читать книги по языку не интересно - хочется надо что то пробовать писать. Для этого необходимо понять:
  • в чем писать (IDE)
  • как это запустить
  • где это все хранить

... в чем писать (IDE)?

Альтернатив как бы особо то и нету. Конечно же, кроме Visual Studio есть сторонние IDE для работы с C# кодом, но больше напоминают поделки студентов.

... как это запустить?

есть нечто напоминающее JDK - .NET framework. Включает в себя виртуальную машину, базовый набор библиотек и инструментарии для отладки и разработки. Похоже, что есть 4 основные (переломные редакции):
  • .NET 1.0 - самая первая и самая убогая версия. В данное время практически не используется.
  • .NET 2.0 - первая доведенная до юзабельного состояния версия. Вылечили многие детские болезни 1.0. Начали интересные синтаксические отличия от Java :)
  • .NET 3.5 - не только язык, но и платформу перекопали на столько, что у многих библиотек появились версии до 3.5, и после 3.5. Также, полным ходом внедряется элементы из функциональных языков.
  • .NET 4.0 - уже не самая новая, но вполне свежая и актуальная версия. "Типа" много усовершенствований, новая версия виртуальной машины CLR, доработан UI фреймверк и т.д.

... где это все хранить?

По поводу кода - у VS есть вполне достойные плагины для работы с SVN и Git репозиториями.
По поводу настроек - тут все немножко сложнее (по сравнению с Eclipse). Настройки проектов и солюшенов хранятся в файлах sln и csproj. Как правило, эти файлы вместе с исходниками находятся под контролем версий. А вот глобальные настройки IDE (горячие клавиши, окна и др.) хранятся в "Мои Документы/Visual Studio XXXX" и об этом желательно не забывать, чтобы после перестановки ОС не было "мучительно больно":)

Миграция на .NET платформу

После долгого писания на Java, выдалась возможность вплотную познакомится с MS .NET. В начале, незнание платформы вызывало чувство раздраженности и полной беспомощности, но позже, начал вырисовываться круг того, что надо выучить, понять и выполнить.
Далее мои основные впечатление о том, как перестроиться на .NET платформу в смысле обустройства рабочего пространства и налаживание эффективной работы.
У меня получилось следующие группы того, что срочно необходимо сделать или узнать, для того, чтобы начать эффективно работать:
  1. Базовый инструментарий - в случае с .NET надо разобраться а) какие .NET Frmaework -и бывают. как их ставить; б) определиться с IDE
  2. Начальные сведения о платформе - а) основы синтаксиса C# б) минимум знаний чтобы создать, скомпилировать и запустить проект
  3. Эффективный локальный инструментарий - инструменты на локальном компе
  4. Основная информация о платформе - а) минимальный набор знаний чтобы начать работать б) места, где можно найти нужную информацию
  5. Базовые фреймверки - xUnit, Mock, UI (RCP, Forms), XML (DOM, SAX, serialization etc)
  6. Инструментарий для жизни проекта - Build tool, CI server etc
Чет дофига получается... поэтому буду вставлять ссылки по мере написания сообщений.

вторник, 24 июля 2012 г.

Enterprise интерфейсы

Enterprise приложения имеют корявые интерфейсы. И не просто карявые, а исключительно уродливые и неудобные! (крик души :( )

Исходя из наблюдений, этому есть 2 главные причины:
  • 'Нам это не нужно' или 'некогда заниматься'
  • Дизайн делают программисты


'Нам это не нужно' или 'некогда заниматься'

Как ни странно, но заказчику 'некогда' и 'незачем' всякими там красивостями заниматься. Например, на нескольких последних проектах, заказчик 'не смог' найти подходящие иконки для своих кнопочек, тулбарчиков и и даже 'не нашлось' символики для страниц «about». А уж про всякие там дизайн, юзабилити и прочую ересь даже и вспоминать не приходится.

Дизайн делают программисты

Это вообще отдельный предмет восхищения. Вроде бы умные люди, но как начнут рисовать удобные интерфейсы... Достаточно вспомнить корпоративные системы (Service/Help desk, jira и т.д.). А если еще на запутанные страницы визарды натянуть AJAX – так вообще загляденье получается.

Из недавнего

Образцово-показательный подход программиста к проектированию UI: Есть сущность. Допустим человек. И есть около десятка списков, которые характеризуют связи этого человека – например список детей, машин, сотрудников, домов и т.д. Вообщем совершенно разнородные данные.
Так вот, подход программиста к построению UI для управления этими списками: а давайте сделаем таблицу, в которой каждая колонка будет представлять конкретный список. Т.е. есть таблица с сортировкой по колонкам, выделения выбранной строки раскраской четных строк и т.д.. И в этой таблице первый столбец это 'дети', второй столбец это 'машины', третий это 'сотрудники'. И таких столбцов порядка 10-15!. Возникает 2 вопроса: 'Почему именно так?' и 'Что в этом случае будет представлять строка этой таблицы?'.
Ответы поражают еще больше чем предложенная идея: 'Так будет компактней. А то, что столбцы вообще не связаны другом с другом, дык это не беда. Ведь и так же все понятно.'

пятница, 22 июня 2012 г.

C# и VS - "первые" впечатления

Очень давно не работал с MS Visual Studio и впервые "серьезно" столкнулся с .NET платформой. Общее впечатление: "Насколько многообещающая платформа и настолько убогая IDE".

Язык

Язык платформа богаче чем Java. Есть много полезных и (не очень) плюшек. Впечатлили region-ы для разметки кода... и MSDN на русском. "По управляемости" и "возможностям языка" C# ближе к С++, чем к Java.

MS VS

Студия - убожество. Такое впечатление, что про рефакторинг в MS "узнали" только в 2010 году. Эффективно работать с кодом невозможно (переход по ссылкам, outliner, открыть класс по имени, открыть класс по имени и т.д.). Комбинации клавиш поражают своим удобством.
Особо порадовало, что в начальных версиях не открываются проекты с юнит тестами. Наверное TDD это очень большая роскошь в мире MS.:)

Тулзы

Пока я плохо представляю, как можно работать в "голой" студии. Впечатлил "решарпер". Продукт делает VS пригодной для жизни для эффективной работы с кодом. Также "впечатлила" стоимость этих продуктов (при том, что эту цифру надо прибавить к стоимости самой студии и M$ Win).

пятница, 1 июня 2012 г.

Пора списывать?


FireFox стал громоздким, тормознутым и нестабильным (IMHO). Единственное что удерживает - FireBug. Еще одна Opera?

суббота, 26 ноября 2011 г.

Цифры

Некоторые выводы:

Цифры/сроки

От 20% до 50% времени уходит на активности "около работы". Т.е. если эстимейт предполагает на 1 мес. разработки, то все может затянутся на 2 календарных месяца.


Зависимость кол-во оверхедов от длинны проекта не линейная. Если проект маленький - оверхеды маленькие. Скорее всего потому, что к проекту относятся как к чему то временному и не существенному.
Если проект средний (12-18 ес), то оверхед просто громадный. Объем работ не сильно большой, а подготовка/бюрократия уже "не детская" (тяжеловесные подходы к организации процессов).
Если проекты большие, то оверхеды начинают теряться в общей массе (по появляются др. моменты, связанны с "затяжными прыжками").


Напряженная работа начинает напрягать где то к концу 2-3 недели. Появляется дискомфорт и чувство усталости. Ритм 2 недели "по полной", потом неделя "на расслабоне" дает неплохие результаты.

Овертаймы начинают чувствоваться к начал след. недели. 5 дней + овертаймы + еще пару дней - еще можно работать. Далее начинается спад продуктивности, внимательности и т.д. Как можно работать 5-7 недель без выходных - для меня загадка...


Общение с заказчиком


Отсутствие обратной связи от заказчика, начинает напрягать уже к концу 2-го релиза. ~1 недели молчания после поставки достаточно, чтобы команда немного напряглась. К 2-3 релизу это перерастает в легкую форму пофигизма.

В среднем, задержка полноценного фидбека может достигать 1 релиз. Делаем уже 5-й, а получаем окончательную информацию только по 3-му. Календарное время - примерно 1-2 мес.

Наверное стоит держать контекст фичь еще, как минимум 1 мес. после релиза. А лучше 2-3.

Акцент заказчика может оказаться самым неожиданным для вас. 70% вопросов задаются по "очевидным" для вас моментам. 25% по мутным и недостаточно документированным фичам, и 5% вопросов обращаются к по настоящему проблемным местам, которые не были известны вам.


коммиты/поток изменений


Самый большой барьер - начало.
Начало проекта. Необходимо приложить все мыслимые усилия, чтобы в начале проекта работа началась. Первые 10-20 коммитов очень важны. Нужно лить что угоно (струкру директорий, скелет проекта, шаиблоны и документу) - не важно, важно чтобы лед тронулся. Когда люди начинают работать с СВН и ВИКИ, то начинают появляться вопросы, начинаются шевеления и команда начинает движение вперед.
Начало релиза. В начале релиза наблюдается провал. Не такой громадный, как на старте проекта, но все же... Старое сделали, новое еще не начали. Что делать? Когда и с чего начинать? Главные и второстепенные цели этого релиза. Надо приложить максимум усилий, чтобы ответить на эти вопросы (и донести ответы до команды). Без этой информации наблюдается штиль. Возможно, лучшим вариантом было бы начать отвечать на эти вопросы уже в конце прошлого релиза (умным языком "начинать планировать следующий релиз, в конце ткущего"), но в реальной жизни небольших команд не всегда это получается. Релизы обычно довольно напряженные, основной фокус - поставка, а вопросы анализа и планирования как то теряются.


Максимум активности - середина и конец релиза. Середина - все на крейсерской скорости. Конец - все "в теме", и происходит куча небольших исправлений (допиливаний). Начало релиза - не совсем понятно с чего начинать и иногда требуется доработка дизайна.

суббота, 15 октября 2011 г.

"Интересный" проект

Текущий проект подходит к концу. Скорее всего, это один из самых "тяжелых случаев" в мое практике. У нас случилось все: и набор команды "с нуля", и неизвестные/малодокументируемые технологии, и полная неразбериха с ресурсами (и временем и баблом), и критическая концентрация идиотов на душу населения мешающих факторов, и траблы с железом, и необходимость разбираться с тем, чего так долго удавалось избегать(например multithreading и JS).

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

пятница, 31 декабря 2010 г.

31 декабря - Работаем!

Человек, который надеется что 31 программист будет эффективно работать, либо садист, либо имбицил.

понедельник, 13 декабря 2010 г.

Немножко о холиварах

Предыстория

Решил попробовать Google Chrome (GC) на работе . Основной причиной было:
  • более удобная строка ввода адреса (совмещенная с поисковиком)
  • бОльшее пространство под страницы. У FF это Заголовок окна + строка ввода + верхняя панель + закладки + нижняя панель, у GC Закладки + верхняя панель
  • ну и конечноже 'восторженные вопли очевидцев': да он супер!, да он реактивный!, да он кульный/гламурный и т.д.

Проблемы с памятью

После запуска насторожил объем использованного ОЗУ. Решил провести 'следственный эксперимент':
  • Открыто порядка 20 закладок. Немного JS, и очень чуть-чуть Flash (несколько банеров)
  • Google Chrome 8.0.552.215, FireFox 3.6.12. Оба портабельные версии, установлены все необходимые плагины/дополнения
  • Оба браузера стартуют с USB-HDD (дабы ограничит скорость чтения + протестировать работу в боевых условиях)

По очереди запускаем браузеры и смотрим на использование ОЗУ (Windows Task Manager).
Результат меня поразил: FF: 260MB, GC: 1210MB.
В принципе на этом этапе уже все стало ясно: это абсолютно не допустимо тратить 1,5ГБ памяти на 20 страниц (тем более в свете того, что для программистов память это довольно ценный ресурс).
Но, решил проверить "скорость работы".

Оценка быстродействия

Этап 1. От "Клик на иконку" до "Видим готовое к использованию окно (страницы еще не недогруженные)" FF: 6 сек., GC: 1-3 сек.
Этап 2. От "Видим окно" до "Полное восстановление сессии (все страницы загрузились)". FF: 20 сек., GC: 58 сек!!! (30 сек на определении proxy и 28сек. на загрузку всех страниц)
Этап 3. Открытие новой страницы и повторное открытие той же страницы. FF: 5сек/2сек, GC: 5сек./4сек. В качестве примера взята демка icefaces: удивило более быстрое повторное открытие в FF (кеширование или работа JS интерпретатора??).

Выводы

  1. Если вы думайте, что ваш FireFox кушает много памяти, запустите Chrome. Для меня 1200МБ для 20 страниц это непозволительная роскошь!
  2. Похоже, что хваленный быстрый старт Chrome это очередной лохотрон от великого и ужасного. Вспомнился 'более быстрый' старт WinXP по сравнению с Win2000
  3. В работе оба браузера примерно одинаковы. Какой-то супер скорости одного перед вторым замечено не было
  4. В хроме ужасно неудобно работать с закладками
  5. В хроме не нашел некоторых очень полезных плагинов, например WebDeveloper, ScrapBook и FlashGot
Похоже что Chrome пока 'не катит' на роль рабочего инструмент программиста.

среда, 1 декабря 2010 г.

О декомпозиции методов

Часто приходится встречаться с длинными методами. Реакция на 'это' может сильно зависеть от сложности и времени суток: от "ничего сложного, щас разберемся!" (утром), до "дайте я кого нибудь пристрелю!" (под вечер, когда натыкаешься на 'это' под конец рабочего дня).
Попытки разбить длинный метод на 'много маленьких' не всегда заканчиваются успешно... и регулярно возникают вопросы: 'почему так?' и 'что с этим делать?'

пятница, 29 октября 2010 г.

portable soft

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

Тестировщики, хватит заниматься обеспечением качества (перепост)

Недавно вот познакомился с интересной статьей.

воскресенье, 10 октября 2010 г.

Тестер враг разработчику

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

Подобные заявления я обычно воспринимал как специфический миф-поверия из мира IT:)

Недавно вот наткнулся на заметку Живут, как тестировщик с программистом, где автор всерьез обсуждает проблему такого взаимоотношения.
Вторым настораживающим "знаком" была подпись автора вот этого блога (см. левый верхний квадрант, под меню).

Напрашиваются следующие выводы:
  1. Похоже что миф-поверие имеет весьма тики реальную основу (даже не смотря на всю иррациональность подобного поведения)
  2. Есть подозрение, что чем крупнее масштабы конторы компании, тем такое поведении более ярко выражено. Кому-то выгодно подстегивать соревновательный дух таким способом?!
  3. Есть такое наблюдение: большинство трудов об автоматизированном тестировании для разработчиков (TDD, JUnit и т.п.) имеют целые разделы о том, что программисты не любят заниматься тестированием, потому как а) это неинтересное и бесполезное занятие б) это занятие для низших форм жизни. Возможно, значение последнего де мотивирующего фактора (занятие для низших форм жизни) значительно недооценивается

понедельник, 13 сентября 2010 г.

Вопрос по Луркоморью графам

Вместо вступления

Как показывает практика, вот это безобразие на самом деле никого особо не волнует, и контора готова платить за плевание в потолок потери 2-3 и более часов в день. Ну и ладно - пытливый ум способен найти себе занятие (и 'освоить' офисный канал:) ).
Так вот, наткнулся я вот на этот замечательный сайт, и оказалось, что осознать всю глубину написанного мне мешает недостаточное знание русского-матерного и всяких там сленговых словечек. Благо, существует довольно подробные разъяснения практически всех непонятных слов и выражений (интересно, познавательно и с картинками).
После того, как количество закладок в браузере превысило отметку 30, родился резонный вопрос: 'А сколько же это может продолжаться?'

Более форматизированная постановка вопроса

На сколько я понимаю, ближайшая мат. модель - 'граф с однонаправленными связями'. Статья это вершина, связь это гиперссылка с одной статьи на др.
Интересует 3 вопроса:
1. Сколько переходов надо совершить, чтобы посетить все узлы этого графа? Или какой порядок этой цифры?
2. Есть ли несвязанные вершины (без входящих, и исходящий связей)?
3. Есть ли вершины, у которых есть только исходящие связи (т.е. нет входящих)?

вторник, 31 августа 2010 г.

Linux для разработчика

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

Итак, хочется настроить рабочее окружение для java разработки, а именно:
  • JDK 6
  • Ant + Maven
  • Eclipse
  • Увязать это все вместе и интегрировать в системму

Шаги для Windows
  1. Зайти на сайт Sun Oracle, найти и скачать нужную JDK
  2. Установить JDK
  3. Зайти на сайт Apache, найти и скачать Ant
  4. Установить Ant
  5. Зайти на сайт Apache, найти и скачать Maven
  6. Установить Maven
  7. Пробить переменные среды (OS env)
  8. Перезагрузится или закрыть все приложения и перестартовать explorer
  9. Зайти на сайт eclipse.org, найти и скачать eclipse
  10. Установить eclipse
  11. Запустить eclipse и указать установленные JDK
  12. Вытянуть нужные ярлычки

Шаги для Linux (Ubuntu)
  1. Запустить synaptic
  2. Найти пакеты eclipse, sun-java, ant, maven тыцнуть 'Установить' и подождать
  3. Запустить eclipse и наслаждаться ?жизнью? (переменные окружения, ярлыки... вообщем все уже настроено)

Красота!

вторник, 18 мая 2010 г.

Мысль о Research Reports

Мысль навеяна воспоминаем одного друга о прошлой работе и кое какими событиями на текущей...

Вопрос

Насколько эффективно выполняются research задачи?

Небольшое пояснение

Оставим случаи 'пойди туда, не знаю куда', а рассмотрим какую нибудь простенькую задачку, с внятной целью.
Ну например: 'научится маппить связь один-многие в Hibernate'.
Под эффективностью я имею ввиду не численный показатель, а меня интересует вот что:
Допустим задание было дано человеку, который не знает что такое 'связь один-многие'. Этот самый человек скорее всего сделает следующее:
  • сначала почитает что такое one-to-many, заодно и все остальные виды связей;
  • потом он найдет документацию, и прочитает какую аннотацию поставить или что прописать в файл маппинга;
  • затем (если по хорошему) он попробует сделать небольной примерчик, а может даже найдет какой нить hibernate tutorial.
В итоге мы получаем 3 момента:
  • человек потратил примерно день на исследование;
  • формально, результатом этого исследования является всего лишь одна строка кода (аннотация)
  • все остальные добытые знания, в лучшем случае останутся в голове у исследователя
Есть еще неявный четвертый пункт - если этого человека не будет 'под рукой', а понадобится, ну скажем замаппить many-to-many, в этом случае второй 'исследователь №2' проделает почти такой же путь.

Что не нравится

вторник, 4 мая 2010 г.

о том, что 'должен делать разработчик'

Совсем недавно пришлось 'немного' побеседовать с манагерами разных мастей на тему 'что у нас плохо, а что хорошо и что с этим делать'. Я услышал довольно много разных 'разработчик должен делать' и некоторые пункты меня удивили. Вот некоторые из них:
  • разработчик должен знать какого уровня железо требуется для проекта (CPU, память и т.д.). Если вдруг, рабочий ПК тормозит, то разработчик должен (ну просто таки обязан) разобраться в чем дело
  • разработчик должен принимать самое активное участие в усовершенствовании процессов на уровне проекта и на уровне организации
  • разработчик должен заниматься тестированием
  • разработчик должен в совершенстве владеть всеми технологиями, применяемыми в проекте, и по другому просто не может быть