Описанный автором детектив можно было и аналитически расследовать, по собственному коду, вообще не пытаясь дизассемблировать сборки и т.д. (хотя признаю, stacktrace не самый понятный).
Статья интересна, скорее, фактом подобной возможности, разобрать всё до регистров :)
К тому же, работа с нетипизированными датасетами и databiding — не самые очевидные вещи как раз из-за того, что и было описано — в неожиданные моменты могут обработчики зашевелиться, о которых сразу и не подумаешь, что они в принципе могут быть задействованы. И к C# как к языку, все эти ужасы имеют, скорее, косвенное отношение.
Про несколько тысяч долларов — как известно, при оценке стоимости разработанного ПО, часто пользуются человеко-часами и некоторой ставкой за час. Я разрабатываю некий софт для Windows Mobile в свободное от работы время, так же в планах сделать его для IPhone. На текущий момент мои затраты составляют более $15 000, если считать по моей же ставке, по которой я на работе получаю з/п.
Я совершенно без понятия, получится ли отбить эти деньги, но точно знаю, что мне очень не хочется, чтобы мою софтину запиратили :)
Я когда код смотрел, то обнаружил, что там для всего есть русские языковые пакеты, просто язык админки зашит в конфиге, и он не русский ;) Если переключить — всё заработает :)
Если честно, то система достаточно слабенькая. Без обид.
7 лет назад я тоже писал в одиночку CMS на Perl. Очень любил этот язык, да и сейчас уважаю. Скачал CMS, посмотрел — прямо дежа вю! В том плане, что на дворе-то 2009 год, а там всё какое-то древнее и простенькое :)
По существу, то помимо разнообразных архитектурных ограничений системы, прилично и проблем с юзабилити. Да, всё понятно, это сделано программистом-юниксоидом, в аскетичном стиле. Но дизайнер/юзабилист бы совсем не помешал, тем более мы реально не в 2000 году, когда такое ещё могло прокатить.
Критики действительно много, но я прекрасно понимаю, что человеку реально сил не хватит всё переделать, т.к. работы полно, а он один.
Из того, что сразу бросилось в глаза (вперемешку про разное):
2) Везде кнопки редактирования и удаления расположены впритык друг к другу — промазать очень легко
3) Delete confirmation message слишком абстрактный («Are you sure?»), никакой конкретики о том, ради чего этот вопрос
4) У иконок операций над элементами списков нет тултипов
5) Язык админки переключается только через правку config0.pm
6) Все операции проходят через промежуточную страницу, на которой написано «Operation successful.» и линк Go back. Совсем плохо.
7) изменения порядка следования элементов выполнены через гиперссылки в виде стрелок — никакого drag-drop и ajax
8) Система шаблонов — редактируются файлы в textarea. Удобства меньше, чем даже в notepad — какой смысл в таком редакторе? Там же, шаблоны общие, т.е. нет привязки к конкретному языку сайта
9) Работа с Category tree — вообще фантастика, надо видеть этот фарш из голубых стрелочек во все стороны :)
10) после добавления категорий в дерево, в выпадающем меню у контента не обновляется список, чтобы увидеть новый, нужно нажать иконку редактирования
Э, ну… мне 30 лет ;) На «молодого/распальцованного» не очень тяну, как мне кажется. Хотя, конечно, могу ошибаться :) И речь не о «вновь выученном термине», а об устоявшихся терминах, которые удобнее сказать не переводя (и, кстати, не переключая речевой аппарат на правильное английское произношение).
Для меня замена таких терминов на русский длинный аналог, это всё равно, что вместо «бл$» говорить «девица лёгкого поведения» :)
Видимо, есть возможность сделать этот перевод ещё лучше — если авторы перевода задумаются над завязавшейся дискуссией и найдут время на то, чтобы заменить product owner-ов на максимально подходящие варианты перевода — будет шикарно. Главное, чтобы перевод не резал глаз больше, чем его отсутствие :)
Может им на хабре мозговой штурм устроить? Вполне может получиться неплохо :)
Ещё отдельно добавлю — тому, кто не поймёт оставленные без перевода термины, с большой вероятностью, может не хватить образования/опыта, чтобы и русскую часть нормально понять. Без наездов. Объём знаний очень большой упакован в совсем небольшую книгу. Такая высокая концентрация дорогого стоит, но без подготовки может быть избыточной.
Я не переводчик этой книги, я просто защищал идею оставить термины в оригинальном виде.
Ни в чём не повинный читатель… мне duck typing гораздо больше нравится, чем достаточно бессмысленная «утипизация», которая смысла не передаёт, а запутывает. Чтобы понимать термин duck typing, в любом случае необходимо держать в голове «If it walks like a duck and quacks like a duck, I would call it a duck». Иначе «duck» вообще ничего не будет значить.
С термином «утипизация», даже если держать перевод «Если что-то ходит, как утка, и крякает, как утка, то это утка», то лучше всё-таки иметь более полный, к тому же не такой уродливый перевод в лоб — «утиная типизация». (Кстати, погуглил, как термин «утипизацию» ругают :) )
И это не совсем перекладывание работы на читателя. Это предположение, что читаталь обладает достаточным образованием, чтобы понять термин, не переводя его. Мне регулярно приходится в русской речи использовать английские слова без перевода. Правда, когда я их употребляю, я обычно уверен, что тот, с кем я говорю, точно понимает смысл.
С японского традиционно фактически то же самое — непереводимые выражения транслитерируют: дзенкуцу дачи, санчин дачи, гедан барай, маэ гири, учи уке… это стойки, блоки и удары в карате. По-русски коротко не скажешь, а если пытаться брать, например, стойки из самбо (естественно с русскими названиями), то нет прямого соответствия значений — культуры разные.
Возвращаясь к английскому — айтишники всего мира программируют на высокоуровневых языках, в основе которых именно он, английский, поэтому знакомы хотя бы с базой. Так что оставлять английские выражения очень даже логично, чего не скажешь про иероглифы.
Некоторые понятия не имеет смысла переводить, т.к. в русском языке нет устоявшихся аналогов. Тот же Scrum — если начать писать «скрам», то сразу идут визуальные аналогии со словом «срам». Вспоминается мега-ребрендинг у компании Benq в Qisda.
product owner — владелец продукта? собственник продукта?
scrum master — мастер скрама? главный по скраму? ответственный за скрам?
product backlog — незавершённые дела по продукту? невыполненные работы по проекту? план работ по продукту?
Ёмкие и короткие термины перестают быть таковыми при переводе и теряют свою ценность как термин.
В крайнем случае можно их транслитерировать, но тогда надо не забывать и оригинал приводить, чтобы не гадать, как пишется бэклог, если вдруг захочется погуглить про это.
А я, если честно, абсолютно не помнил, что:
1) авторы идеи подобной рекламы сидят в Эпле
2) что эти ролики стоили жуткие миллионы баксов
Зато сам факт наличия этих «I am ...» клипов отлично запомнился. В итоге реклама с девушкой-линуксом для меня чуть ли не часть трилогии OS-oriented роликов от неизвестных авторов (потому что и римейки были, где стебались над всеми и т.д.)
А меня вот как разработчика для мобильных устройств от количества платформ уже мутить начинает. Умею девелопить под Windows Mobile, под iPhone, сейчас ковыряюсь в Android SDK… Симбиан сколько не пробовал, всегда бесил, под него не умею. Теперь ещё одна ОС, блин. Людей от кол-ва браузеров мутит, но разные платформы — это гораздо хуже, чем разные браузеры :)
Если для кроссбраузерности нужно в CSS/JS уродоваться, то тут вообще всё разное — у всех полностью различные SDK :)
Как-то один американский заказчик сказал мне эту фразу, на что я озвучил ему русскую версию поговорки «У дураков мысли сходятся». Ему понравилось, стал периодически подкалывать, что мол, да-да, я помню, как у вас там по-русски это звучит, но лучше не надо :)))
Так ведь целый год с момента выпуска ифона, браузер был единственным доступным способом создавать приложения для ифона! Была опубликована разнообразная документация и т.д. о том, как грамотно делать iphone style веб-приложения. А iPhone SDK появился, грубо говоря, на днях :) Летний WWDC практически весь был посвящён девелопменту под ифон. Все эти акселерометры и т.д.
====
Приложение не должно устанавливать или запускать другой исполняемый код любым из способов, включая без ограничений любые архитектуры загрузки плагинов, вызовы других фреймворков, API или ещё каким-либо образом.
Никакой интерпретируемый код не должен скачиваться и использоваться за исключением кода, который интерпретируется и исполняется средствами Apple Published APIs или встроенными интерпретаторами.
====
Не соглашусь, что mustdie. Совсем недавно ананосировали Qt, который на Windows Mobile работает.
Слил, собрал под свою платформу (несколько часов компилировалось :) ), начал смотреть семплы. Там просто чудовищные Dll-ки тянутся с приложением, и скорость работы не впечатлила ( никуда ничего не улетает и примитивные Hello World грузятся достаточно долго :) ). Хотя масштабы проделанной работы, конечно, поражают, но и MS не лаптем щи хлебает. Т.е. я не ощутил особых преимуществ Qt по сравнением с Compact Framework, кроме существенной кроссплатформенности у Qt. Пролетал тут недавно ролик про запущенные демки на трёх платформах . На первый взгляд — офигенно круто. Но вот когда копнёшь глубже — не всё так однозначно.
Йопрст, это уже больше похоже на опцию «не хочу доставку, просто так заказал» :)
Прикольно бы было, если бы на хабре нотификации об ответах приходили в виде смс-ок, если вместо имейла указан мобильник или бы девушка из контакт-центра звонила и зачитывала :)))))
Да, имейл — это норма на текущий день. В принципе, не считаю это трагедией, честно.
Понял. Могу сказать, что сам пиццу заказываю только по телефону ;) И у них там в базе имейла моего нет, идентификатором выступает как раз телефон.
Полагаю, что вот в таких достаточно специальных случаях можно сделать выпадающее меню «предпочтительный способ связи» и если там телефон — не требовать подтверждения имейла. Другой вопрос, что это может быть геморно с точки зрения реализации, но это уже совсем другая тема :)
В случае с обслуживанием интернет-магазина менеджеру хочется быть уверенным, что его портянка заказов состоит из реальных заказов. Списываться/обзванивать всё равно придётся, но повысится эффективность — если имейл не подтверждён, ещё не факт, что юзер не ошибся при указании имейла. И ещё подтверждение через имейл увеличивает гарантию того, что юзер точно решил что-то покупать. Тот, кто обломался сходить в почту и подтвердить имейл, скорее всего и от заказа откажется. Отказы — это ведь отдельная история, верно?
Я чуть выше описывал механизм удобной, на мой взгляд, регистрации. Так вот в случае, если юзер не получил почту, он волен повторить оформление заказа и указать другие данные.
Статья интересна, скорее, фактом подобной возможности, разобрать всё до регистров :)
К тому же, работа с нетипизированными датасетами и databiding — не самые очевидные вещи как раз из-за того, что и было описано — в неожиданные моменты могут обработчики зашевелиться, о которых сразу и не подумаешь, что они в принципе могут быть задействованы. И к C# как к языку, все эти ужасы имеют, скорее, косвенное отношение.
Я совершенно без понятия, получится ли отбить эти деньги, но точно знаю, что мне очень не хочется, чтобы мою софтину запиратили :)
7 лет назад я тоже писал в одиночку CMS на Perl. Очень любил этот язык, да и сейчас уважаю. Скачал CMS, посмотрел — прямо дежа вю! В том плане, что на дворе-то 2009 год, а там всё какое-то древнее и простенькое :)
По существу, то помимо разнообразных архитектурных ограничений системы, прилично и проблем с юзабилити. Да, всё понятно, это сделано программистом-юниксоидом, в аскетичном стиле. Но дизайнер/юзабилист бы совсем не помешал, тем более мы реально не в 2000 году, когда такое ещё могло прокатить.
Критики действительно много, но я прекрасно понимаю, что человеку реально сил не хватит всё переделать, т.к. работы полно, а он один.
Из того, что сразу бросилось в глаза (вперемешку про разное):
1) Для обычного пользователя поле Groups (взятое из Unix) ни о чём не говорит ( taracot.rh1.ru/cgi-bin/taracot/admin/module.cgi?module=users&page=1&filter=&filter_oncat=&sort=0&action=add ), там должен быть список со множественным выделением. И ведь редактора групп нет вообще, т.е. даже взять их неоткуда.
2) Везде кнопки редактирования и удаления расположены впритык друг к другу — промазать очень легко
3) Delete confirmation message слишком абстрактный («Are you sure?»), никакой конкретики о том, ради чего этот вопрос
4) У иконок операций над элементами списков нет тултипов
5) Язык админки переключается только через правку config0.pm
6) Все операции проходят через промежуточную страницу, на которой написано «Operation successful.» и линк Go back. Совсем плохо.
7) изменения порядка следования элементов выполнены через гиперссылки в виде стрелок — никакого drag-drop и ajax
8) Система шаблонов — редактируются файлы в textarea. Удобства меньше, чем даже в notepad — какой смысл в таком редакторе? Там же, шаблоны общие, т.е. нет привязки к конкретному языку сайта
9) Работа с Category tree — вообще фантастика, надо видеть этот фарш из голубых стрелочек во все стороны :)
10) после добавления категорий в дерево, в выпадающем меню у контента не обновляется список, чтобы увидеть новый, нужно нажать иконку редактирования
Дальше не могу, реально слишком много ужасов :)
Для меня замена таких терминов на русский длинный аналог, это всё равно, что вместо «бл$» говорить «девица лёгкого поведения» :)
Может им на хабре мозговой штурм устроить? Вполне может получиться неплохо :)
Ни в чём не повинный читатель… мне duck typing гораздо больше нравится, чем достаточно бессмысленная «утипизация», которая смысла не передаёт, а запутывает. Чтобы понимать термин duck typing, в любом случае необходимо держать в голове «If it walks like a duck and quacks like a duck, I would call it a duck». Иначе «duck» вообще ничего не будет значить.
С термином «утипизация», даже если держать перевод «Если что-то ходит, как утка, и крякает, как утка, то это утка», то лучше всё-таки иметь более полный, к тому же не такой уродливый перевод в лоб — «утиная типизация». (Кстати, погуглил, как термин «утипизацию» ругают :) )
И это не совсем перекладывание работы на читателя. Это предположение, что читаталь обладает достаточным образованием, чтобы понять термин, не переводя его. Мне регулярно приходится в русской речи использовать английские слова без перевода. Правда, когда я их употребляю, я обычно уверен, что тот, с кем я говорю, точно понимает смысл.
Возвращаясь к английскому — айтишники всего мира программируют на высокоуровневых языках, в основе которых именно он, английский, поэтому знакомы хотя бы с базой. Так что оставлять английские выражения очень даже логично, чего не скажешь про иероглифы.
product owner — владелец продукта? собственник продукта?
scrum master — мастер скрама? главный по скраму? ответственный за скрам?
product backlog — незавершённые дела по продукту? невыполненные работы по проекту? план работ по продукту?
Ёмкие и короткие термины перестают быть таковыми при переводе и теряют свою ценность как термин.
В крайнем случае можно их транслитерировать, но тогда надо не забывать и оригинал приводить, чтобы не гадать, как пишется бэклог, если вдруг захочется погуглить про это.
1) авторы идеи подобной рекламы сидят в Эпле
2) что эти ролики стоили жуткие миллионы баксов
Зато сам факт наличия этих «I am ...» клипов отлично запомнился. В итоге реклама с девушкой-линуксом для меня чуть ли не часть трилогии OS-oriented роликов от неизвестных авторов (потому что и римейки были, где стебались над всеми и т.д.)
Если для кроссбраузерности нужно в CSS/JS уродоваться, то тут вообще всё разное — у всех полностью различные SDK :)
Да и как-то неприлично афишировать вражду с asp.net в блоге .net :(
====
Приложение не должно устанавливать или запускать другой исполняемый код любым из способов, включая без ограничений любые архитектуры загрузки плагинов, вызовы других фреймворков, API или ещё каким-либо образом.
Никакой интерпретируемый код не должен скачиваться и использоваться за исключением кода, который интерпретируется и исполняется средствами Apple Published APIs или встроенными интерпретаторами.
====
Слил, собрал под свою платформу (несколько часов компилировалось :) ), начал смотреть семплы. Там просто чудовищные Dll-ки тянутся с приложением, и скорость работы не впечатлила ( никуда ничего не улетает и примитивные Hello World грузятся достаточно долго :) ). Хотя масштабы проделанной работы, конечно, поражают, но и MS не лаптем щи хлебает. Т.е. я не ощутил особых преимуществ Qt по сравнением с Compact Framework, кроме существенной кроссплатформенности у Qt. Пролетал тут недавно ролик про запущенные демки на трёх платформах . На первый взгляд — офигенно круто. Но вот когда копнёшь глубже — не всё так однозначно.
Прикольно бы было, если бы на хабре нотификации об ответах приходили в виде смс-ок, если вместо имейла указан мобильник или бы девушка из контакт-центра звонила и зачитывала :)))))
Да, имейл — это норма на текущий день. В принципе, не считаю это трагедией, честно.
Полагаю, что вот в таких достаточно специальных случаях можно сделать выпадающее меню «предпочтительный способ связи» и если там телефон — не требовать подтверждения имейла. Другой вопрос, что это может быть геморно с точки зрения реализации, но это уже совсем другая тема :)
Я чуть выше описывал механизм удобной, на мой взгляд, регистрации. Так вот в случае, если юзер не получил почту, он волен повторить оформление заказа и указать другие данные.