Silverlight мёртв?

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

Факты которые следует принять во внимание также представлены тут.

Тема для диплома: стратегии тестирования производительности

Ещё одна интересная тема для бакалавра или магистра: performance testing strategies - "стратегии тестирования производительности" ... а кому этого мало может описать и подходы к увеличению производительности каких то определённых систем - например с теми которые вы работаете .. и включить туда подтему тестирования производительности.

В любом случае - для начала прослушайте данную презентацию.

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

Новый офис

Официально переехали. В понедельник. На практике переселились через коридор. Если раньше был вид на озеро Ülemiste с редким самолётопадом, то теперь вид на старый город и оба залива.

2010-10-27. Tallinn. DDT

Upd: DDT кстати очень хорошо играет джаз. И трубач с тромбонистом у них просто супер!

При чём тут Атлантида

По следам моста поста о "Эстонских Геркулесах"

Нет, конечно Hercules слово конечно используется в русском языке, но он отнюдь не означает античного героя. Хотя последнее тоже того ... не того... ну какие античные герои для современного человека - многие о таких и не слыхали небось. А Геракла знают исклячительно из-за фонтана в Петергофе - "Геракл разрываящий пасть ... кому то там" который наповерку оказывается Самсоном :) (вполне кстати допускаю, что на самом деле речь об одном и том же историческом персонаже), да и то последняя фраза приходит сразу после "Пасть порву, моргала выколю". Кроме того многие путают Геракла, Антея (а самолёт, знаю, знаю), Атланта (а.. это Атлантида? ... не ну тогда тот сильный чувак, на котором небо и балконы, тот явно Геракл - ну подумай сам, при чём тут Атлантида?)

"What?" "What the?"

fun staff

Ещё одна интересная статья поднимающая важные вопросы из области агильного программирования: "Bad attitudes of Agile".

Во первых это всеобщая уверенность в всесильность самоорганизации которая ведёт нас часто к убеждению что менеджеры нас абсолютно больше не нужны. Безусловно, самоорганизация является неотъемлимой частью практики и условием для её применения, но это не даёт нам право говорить о том, что менеджер является абсолютно не нужным балластом в организации  который получает бонусы от работы нас, несчастных практиков, разработчиков програмного обеспечения. Пусть даже в агильном проекте у нас будет кто-то без официального названия менеджер, все равно следующие роли просто необходимо выполнять:
1. Роль лидера проекта. Кто то должен прочетить в общих чертах проект, что мы делаем, как мы делаем, помогать приходить к общему знаменателю в споре и поддерживать команду в трудные времена.
2. Административная роль. Все мы хотим буть самоорганизующимися, но через мгновения мы говорим, "Эй, я программист, и именно этим я хочу заниматься. Почему я должен заказывать воду, организовывать собрания или делать заметки в течении собрания?" или "Бюджет? Да за кого вы меня принимаете? Что, доходность.... ?"

Во вторых. Итеративный принцип разработки программного беспечения часто ведёт к убеждённости, что в проекте нет сроков выпуска - "Ну, мы сдадим проект сразу же после того как всё допишем. Когда? Ну откуда мы знаем как вы будете устанавливать приоритеты или какая обратная связь будет приходить. Сорри - no comments". Всё это мы делаем не смотря на то, что очевидно проект имеет определённый бюджет, определённых клиентов которые заинтересованы узнать предпологаемую функциональность, а так же сроки сдачи проекта, чтобы составить свои планы и так далее. Тот факт, что начальные итерации как правило являются не готовыми к выпуску легко позволяют нам забыть, что общее правило по прежнему гласить, что в конце каждой итерации мы должны иметь продукт готовый к выпуску, и мы говорим "сроков нет" вместо того, что бы сказать "срок примерно такой то, но содержание может варьироваться в опеределённых рамках"

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

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

Снегопад и ARK

Как вы вполне возможно заметили, на улице снег и все остальные прелисти связанные с ним. случайно был сегодня в Таллиннском ARK. Там повальный отказ студентов сдавать сегодня - просьбы "хочу перенести экзамен" донеслись даже до меня :). И правду сказать, вот попали те, которые пришли сегодня сдавать, а привычки то ещё осенние, на зиму надо ведь и перестроиться, а для новичка, не говоря о сдающем, это не так и легко.

ARK кстати работает фантастик! Я еле успел оформить прошение "Милостливый государь, прошу переоформить машину раба божьего .." , как стойка освободилась. И платить теперь можно прямо сразу у тех кто оформляет. Одним словом на переоформление машины и отдачу справок о здоровье ушло всего 18 минут. Я в приятном шоке.

Кстати в Ласнамяевской поликлиннике развод с этими справками по полной программе идёт. Знакомый делал - дали на 5 лет и взяли 250. Хотя на 5 лет дают только очень пожилым или больным. Остальным 10 и 200 ЕЕК, а в Мустамяе, так вообще 150.

Чем мы тут занимаемся

На всякий случай уточню, чем именно мы тут в нашей фирме в Эстонии занимаемся.

По данной ссылке можно найти описание нашей системы, подхода и стратегии. Финансовая (бухгалтерская) консолидация - the aggregation of financial statements of a group company as a consolidated account.

Лучше всего нас характеризует конкуренты. Один из них например Tagetik. У них на странице можно найти много презентаций и красивых картинок :). Другой конкурент который в сегменте повыше и из пд которого мы пытаемся выбить стул - ORACLE-Hyperion. Где то ещё выше находятся Microstrategy и SAP, но мы с ними не конкуренты конечно.


PS: вы кстати удивитесь, но реально очень многие до сих пор используют Excel для конослидации, нахождения позиций по валютам (currency hedge) итд и не собираются от него отказываться.

Промежуточные результаты компании по поиску персонала - программистов на .Net

Суммируя промежуточные результаты компании по поиску персонала - программистов на .Net в соответствиие с данным объявлениями noorem, vanem и следующими позициями

1.    Entrance level – Junior Developer: We are ready to give a fair chance to young developers who do not have a long experience of developing software in one or another programming language. The key skills are: an ability to develop, algorithmic thinking and team work. Salary level: 15 000 – 20 000 depending on experience and skills

2.    Advance level – Developer/Senior Developer: Master of Science or a student currently studying on the master level. Ability to generate a program code with a high quality (from the algorithm perspective and number of bugs) in a reasonable time frame avoiding over-complication of tasks. Salary level: 30 000 – 40 000 depending on experience and skills

1. Количество обратившихся
    На noorem - 14
    На vanem - 7

2.    Из них
    - Никогда не имели раньше дело с профессиональным программированием: 8
    - Без высшего образования: 3
    - С высшим или полувысшим образованием: 10
    - С неоконченным или не профильным: 5
    - Девушек: 1
    - На текущий момент без работы (и не учаться): 5
    - Средний возраст: Три группы примерно одинаковые по численности: 23-24, 27-34, 36-51
    - Иностранцев: 1

Интервью:
1. Четверо отказались: Двое нашли что то другое, двое просто развлекались закидывая CV - безпричинный отказ или желания не соответствующие нам по технологии, хотя последнее чётко указано в описании работы
2. Выбрано на интервью: 7 человек (из них претендовало на noorem - 5, на vanem - 2)
3. В качестве практической работы на месте (в течении часа) оба претендовавщие на vanem  выбрали простейшую сортировку чисел и в принципе только с этим и справились (с большими оговорками).
4. Ни один на старшего программиста даже близко не подходит. В силу отсутствия соответствующих навыков. Несколько человек скорее на уровне стандартного специалиста.
5. Оченивались по критериям:
   - Оценки университета: Математика / программирование
   - Ответы на вопросы: SQL, .Net, структуры данных и математическое мышление
   - Практическая работа на месте (в течении часа, задания по выборы)

Результаты поиска (пока): скорее отрицательные чем среднии и тем более никак не положительные.

"Несчастный случай"

Новый альбом

ПС: 
1. :) особенно первая
2. :) антипиратский способ распространения

Тема работы из ниоткуда

Ещё один пример как можно найти тему для работы бакалавра из ниоткуда: Error handling in SOA

Эстонские Геркулесы

Из центрального русскоязычного телевидения Эстонии - "Наши силачи, эстонские Геркулесы..."

Либо я что то не понимаю, либо в русском языке латинское слово действительно не используется - только слово Геракл / Гераклы.

SOS

FYI (из Wikipedia)

«May day»: Фраза представляет собой приблизительную английскую транскрипцию французского m'aidez — сокращённый вариант фразы venez m'aider («придите мне на помощь», «помогите мне»). В стандартном французском ни m'aidez, ни m'aider не используются как призыв о помощи. В случае опасности французы восклицают «À l’aide!» или «Au secours!».
Mayday был придуман в 1923 году Фредериком Стэнли Мокфордом, старшим радистом аэропорта Кройдон в Лондоне. Его попросили предложить сигнал, который было бы трудно перепутать с обычными радиосообщениями и который мог бы быть легко понят в условиях плохой радиосвязи. Выбор Мокфорда объясняется тем, что большинство полётов из Кройдона в то время осуществлялось в аэропорт Ле Бурже в Париже.

Большая Разница "Полиция"

:) "Но что мешает нам - только имя"

В верхнем правом углу выбор эпизодов - перейдите на третий эпизод

Темы дипломных работ

Для студентов ТТУ: На данной странице представлены темы дипломов в которых я готов был руководителем

TDD - ложное чувство защищённости

Коментарии по следам "Agile Ruined My Life"

TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes.

TDD is good for braindead simple crap programming where you have a well defined set of requirements and need to slog through them. I used it today when I needed to write about 30 java classes to fill in the functionality of an app I had built. That allowed me to both ensure that I had all the details working and test the framework itself and ensure it did everything I intended it to do correctly.

Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.
By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break.



TDD - очень популярный подоход на сегодняшний день. Но всегда необходимо помнить, что многие инструменты не универсальны а значит нужно чётко определиться, для чего данный инструмент подходит и будет спасением, а для чего использование данного инструмента будет не только бессмысленно, но и опасно.


Note: собственно ещё одна возможность написать превосходную работу с наналитическим уклоном и защитить диплом

Роль архитектора в Agile Development

Интересная тема для размышления и написания работы бакалавра или магистра: Роль Архитектора в агильной разработке.

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

Примерно то же самое описано в данной статье, но более упорядочно (пункты) и даже с презентацией.

IKT TTU

к сведению

Lugupeetud doktorandid,

IKT doktorikool kuulutab välja stipendiumikonkursi. Stipendiumi saavad taotleda kõik doktorikooli doktorandid, kes õppivad doktoriõppes täiskoormusega, ei saa doktoranditoetust teistest allikatest, ei viibi akadeemilisel puhkusel ning ei ole ületanud nominaalse õppeaja. Määratakse 10 stipendiumi. Ühe stipendiumi suurus on 6000 krooni kuus ning stipendium määratakse üheks õppeaastaks. 

Stipendiumi taotlemiseks tuleb esitada taotlus.

Taotluse elektrooniline vorm on kättesaadav doktorikooli kodulehel aadressil http://iktdk.dcc.ttu.ee/form_3.html

TAOTLUSTE ESITAMISE TÄHTAEG ON 18. OKTOOBER 2010.

Вроде не первое сентября

так что поживём увидим ..... из новостей

Главной темой встречи глав компаний было обсуждение возможных форм сотрудничества для совместного противостояния Apple, лидерство которой на рынке мобильных устройств становится все заметней. Среди прочих возможных вариантов обсуждалось и предложение Microsoft купить компанию Adobe.

TV3

Я не понимаю, почему перевод с эстонского на русский в актуальной камеры ТВ3+ идёт с таким огромным эстонским акцентом?!

Тема для бакалавров

Интересная тема для написания бакалаврской работы .. например "Применение OAuth 2.0 .... в какой нибудь локальной системе".

Не пора ли нам готовиться к agile crash?

Одна из лучших статей которых мне довелось прочитать за последнее время - Agile Ruined My Life.

Честно говоря, последнее время, происходящее вокруг данной технологии, очень сильно напоминает времена перед крахом дот комов. Тогда, изначально превосходная идея, рухнула не в силу своих изьянов. Скорее в силу того, что мы использовали не соответствующие подходы, не достаточные инструменты для разработки и примениния .... да и вокруг идеи было достаточное количество людей и фирм которые скорее использовали идею нежели развивали её, в надежнее быстро и по лёгкому получить прибыль .. и желательно большую прибыль. И лишь сегодня, медленно, с правильными инструментами, исходная идея виртуальных представительств обретает своё истинное очертание.

Значит ли эт, что и agile придётся пережить подобный кризис в скором будущем? Или она устоит под напором псевдо знатоков, псевдо применения, псевдо проектов и псевдо правды?

Кстати, вот одна из презентаций, где у меня появляется устойчивое чусвство, что говорит человек который не доконца понимает о чём он говорит (Trainers who can't do the work)

Отрицательные примеры

Забавное интервью. Привлекло моё внимание высказываниями о Фоменко, вернее тем как они сформулированы, что показывает насколько нужно быть акурратным формулируя свою мысль. В данном случае - фрагмент с 1:57 - звучит абсолютно чудовищно, хотя скорее всего таким не является. Озвученная мысль сводиться, в кратце, к следующему: у нас имеется 15-100 экспериментов доказывающие правильность теории Х. При появлении отрицательного примера, т.е. которое не укладывается в наши рамки, мы его просто откидываем мотивируя нашими предыдущими 15-100 экспериментами. Бред какой то.


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

Repost: Wanted: new scientific talent

(in English) Wanted: new scientific talent

Иероглифы .. а так же немного научного подхода перемешанного с историей

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

1. Как возникают разные подходы к расшифровке, при чём оба варианты мне импонируют. Первый из них математический - сравнение групп и отдельных символов с целью построение частотной таблицы - гипотеза: символы втсречающиеся одинаковое или похожее количество раз в оригинале и переводе должны быть эквивалентны. Томас Янг.

Второй вариант найти похожии языки и попробовать восстановить из более современного (но достаточно древнегео что бы быть праямым потомком) языка - вернее его символов, символы более старого языка. В виде более современного языка был использован коптский язык. Жан-Франсуа Шампольон.

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

Собственно расшифрованное Янгом создало мощную базу для Шампольона - например то как переведёно слово Клеопатра (вернее показана как оно записано иероглифами).

2. Второе, что мне особенно понравилось, это узнать переход от иероглифов к звукам и буквам. Уже зная процесс всё кажется очень естественным. Вначале мы пытаемся записать и придумывая мы используем символы для обозначения слов отображая их. Как и во многих пиктограммах и иероглифах. Затем у нас появляются более сложные концепции изображение которых трудоёмко, поэтому мы вынуждены придумывать переход и запись по символно или звуками. При этом, придумывая буквы, естественно использовать либо предыдущие иероглифы, либо окружающие нас предметы: например изображение льва как буква Л (англ ссылка на полный текст). Собственно подробнее здесь

Собственно в передаче не опоминается важный факт, что в многих древних языках глассные не писались. Например Рамсес читалось и без глассных звуков (согласные RMS[S]).

Экзосклеты

Интересная, научно-популярная, статья о экзосклетах.

Простые правила необходимые при использовании: binding, xaml, .Net 4.0

Пост для тех, кто скорее чуствует себя новичком в xaml, binding, .Net 4.0


Правила, которые нужно помнить чтобы WTF - понять почему binding в xaml не работает 

1. Переменные нельзя использовать в binding/xaml, только свойства, поэтому
когда мы пишем

Text="{Binding MyVar, Mode=TwoWay}"

вместо того чтобы использовать в декларации класса

Public MyVar as integer

используйте

Public Property MyVar as integer

ХОТЯ

2. Кроме того вам скорее всего понадобиться "выкидывать" извещения о изменениях в бизнес объекте для обновления UI, поэтому используйте OnPropertyChanged (link) и описывайте оба: Get и Set части свойства вместо короткой записи которую мы видели выше.

3. Не забывайте, что бы обновить UI при использовании таких простых и удобных классов как lists, dictionaries вам понадобиться сделать rebind (определить заново DataSource, ItemSource) ... либо используйте observablecollection etc (link)


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

<controls:ChildWindow.Resources >

        <loc:RO_FavImageTypeConverter  x:Key="FavConverter" />
    </controls:ChildWindow.Resources>

...

<Image Source="{Binding Favorite, Converter={StaticResource FavConverter}}"/>
...

Public Class RO_FavImageTypeConverter

  Implements IValueConverter
 
  Public Function Convert(ByVal value As Object, ByVal targetType As Type, ByVal parameter As Object, ByVal culture As Globalization.CultureInfo) As Object _
  Implements System.Windows.Data.IValueConverter.Convert
 
    If value Is Nothing Then Return Nothing
    Dim bIsFav = DirectCast(value, Boolean)
    If bIsFav Then
      Return Utility.ImageHelper.GetImageSource("Resources/favor_yellow.png")
    Else
      Return Utility.ImageHelper.GetImageSource("Resources/favor_grey.png")
    End If
 
  End Function

PS: Прописование конвертера в xaml можно легко найти в сети.

2. Обратите внимание, что вы можете использовать параметры конвертера. Например:

Text="{Binding Amount, Mode=TwoWay, Converter={StaticResource nmbFormat}, ConverterParameter='n0'}"

НО! обратите внимания, что такие варианты достаточно статичны. Поскольку нельзя использовать в binding более одного свойства.

Рассмотрим к примеру вариант, когда мы имеем класс с двумя свойствами - Значение и Формат. Мы можем использовать binding для Значения, но не можем так же передать Формат в функцию конвертации. Мы конечно можем исхитриться и передать в конвертер весь представитель класса но в таком случае у нас возникнет проблема с обратной связью (TwoWay binding) поскольку в обратный конвертер мы получил значения поля (изUI control), которое должно быть занесено в поле преставителя класса, но binding то был сделан на всего представителя (instance), а  не только одно поле, а значит автоматика не сработает.