Адекватность, желание учиться и минимальные навыки — требования по дефолту, посему не обсуждаются. Опыт приходит во время.
P.S. Цукерман сделал фейсбук, будучи студентом, и неумея программировать. Сделал по книжке для чайников. Дуров тоже осваивал php, пока писал вконтакт, стянув идею и дизайн у Цукермана.
У меня знакомый решал подобную задачу. У него была трехлитровая банка вишни, ему нужно было посчитать сколько водки нужно туда было залить, чтобы приготовить настойку. И решил он ее в одно действие, ибо студенты технических вузов знают на зубок цифру заполнения в 61 объемный процент.
1. Если код проходит юнит тесты, это абсолютно не значит, что он правильный. Юниты никогда не покрывают всех возможных состояний и вариантов исполнения кода. Более того, тесты, проверяющие «граничные» и «критические» значения остаются в большинстве случаев «за кадром». Поэтому сложные и редкие ошибки не выявляются юнитами.
2. Любые утверждения, что юниты экономят время, безосновательны, потому как юнит тесты не исключают дебага. А если сделан пошаговый дебаг, большого смысла в юнит тестах я не вижу. Все говорят об эффективности и правильности юнитов, но никто до сих пор наглядно так и не доказал это.
3. Заранее просчитать результат выполнения сложной функции не представляется возможным, не выполнив ее перед этим. Только пошаговый контроль в дебаге сможет выявить, что вычисленный результат верен. Если юнит не сработал, так или иначе придется дебагить.
4. Юнит тесты сложны в поддержке. Код меняется по мере разработки — тонны юнитов летят в корзину. Если Вы делаете одно простое изменение в коде, Вам нужно перелопатить десяток тестов.
Безусловная полезность юнитов и TDD является в том, что самого начала заставляет быдлокодеров заботиться о компонентной модели кода и декомпозиции функционала.
Если Вы генерите XML из базы данных, то не совсем понимаю зачем вам XSL. Кроме того есть куча графических мепперов, в которых пользователь мышкой таскает поля, а XSLT генерится сам. Ваша компания могла бы сэкономить приобретя один из них.
> Почему вы не используете субпиксельное позиционирование, дорогая Microsoft, ответьте! Ответа нет.
Ответ очевиден. Все дело в API. GDI32 использует пиксельную привязку к координатам. Поэтому и позиционировать по строке, например курсор, можно только в целых числах. Современные графические библиотеки, в том числе и GDI+, уже давно используют дробную арифметику, но видимо всплыли проблемы с совместимостью со старыми API, либо GDI+ просто лежит леером поверх старого GDI32.
Самая полезная фича была бы на сайтах знакомств: «сегодня этот парень написал также»… и далее стоит список анкет, которым писали эти товарищи.
Дело в том, что на подобных сайтах есть категория дрочеров, их меньше 1%, которые засирают анкеты девушек 99% месседжей. Они сидят днями и ждут появления новых анкет, чтобы написать «Привет, крошка, как дела!». В итоге прочитав в первые пару дней 200 подобных сообщений, девушка устает и теряет всякую надежду.
Я вот одного не понимаю. Почему такие разводы не попадают под статью «вымогательство»? Номером владеет не Анонимус с улицы, а вполне конкретный и идентифицированный человек, которого можно привлечь за «сообразительность».
Насколько я понял идею — это создать кучу DSL которые позволят программировать декларативно, а компилятор и runtime научить распараллеливать выполнение декларативных кусков. Так?
DTO-это стандартное и правильное решение. Но часто люди хотят упростить себе жизнь, имея доступ прямо к объектам. Как-то стояла задача отдавать объекты хибера апликации GWT. Для этой цели я использовать Gilead, который автоматически депроксирует хиберовские бины, заменяя не только проксированные ссылки, но и коллекции.
В Java условия Йоды употребляются повсеместно со строками:
if ( «OK».equals( str ) )…
вместо
if ( str != null && str.equals( «OK» ) )…
Если str == null, NPE не выскочит, а условие обработается корректно.
«Покемонные» эксепшны тоже необходимы, когда при отлове любого эксепшна нужно сначала выполнить общий кусок кода, а затем частные действия.
По-моему все гораздо тривиальнее. Причины заката Borland — неадекватная ценовая политика. Когда MS пихала свои IDE всем кому не лень за символическую цену, полный пакет продуктов Borland стоил несколько k$. Причины успеха в России — все это можно купить было на пиратском СД за пару баксов, и на паскале учат программить в школах.
Автор, Вы-таки не правы! Перенимая у Самизнаетекого любовь писать словами на русском языке, Вы безусловно сделаете интерфейс грамматически верным с лингвистической точки зрения. Однако пользователь не любит читать. Более того, его скудная извилина реагирует только на привычные ему штампы. Заполнив кучу полей формы, единственная кнопка, которую он ищет должна быть жирная «OK» (как Вы думаете, почему в Microsoft не додумались также поменять безличные Ok-Cancel-Apply?). Вы же его своим «Оставить комментарий» заставляете читать и лишний раз вдумываться: «а то ли сделает эта странная кнопка, что мне в самом деле нужно, если я вот сейчас возьму и нажму ее»?
Если хотите быть таким креативным, сделайте кнопку «Х… як!» — пользователю будет интуитивно понятно, а заодно и повеселит.
А где же в графиках самое основное, для чего существует этот сайт: «секс на один-два раза?» ))
На самом деле выводы автора не совсем верны. Например «с возрастом меньше курят». График говорит, лишь о том, что молодежь курит больше. Но совсем не обязательно (и скорей всего нет), что с возрастом они бросят курить.
Сейчас рано делать ставку на эту технологию. Кроме того пройдет немало времени, прежде чем все клиенты будут поддерживать ее. Поэтому лучше использовать оболочку для дуплексных коннекшнов, которая снизу умеет работать как с Comet, так и с WS. Для серверной части это фреймворк Atmosphere. К нему существует куча клиентов, например JQuery plugin: jfarcand.wordpress.com/2010/06/15/using-atmospheres-jquery-plug-in-to-build-applicationsupporting-both-websocket-and-comet
В своем проекте я использовал GWT Comet. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.
> WebSocket — протокол полнодуплексной двунаправленной связи поверх TCP соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
Один реализуется поверх другого. Отличие примерно такое же как между JavaScript и JQuery. Но цель у них одна — дуплексный обмен данными в реальном времени. Использовать голый TCP в окружении браузера проблематично — это не юникс, и с тредами здесь проблемы. Поэтому добавили асинхронный JavaScript API для пакетного обмена.
Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.
P.S. Цукерман сделал фейсбук, будучи студентом, и неумея программировать. Сделал по книжке для чайников. Дуров тоже осваивал php, пока писал вконтакт, стянув идею и дизайн у Цукермана.
Все остальное, что Вы написали — херь.
douglasernstylp.files.wordpress.com/2010/10/office_space.jpg
1. Если код проходит юнит тесты, это абсолютно не значит, что он правильный. Юниты никогда не покрывают всех возможных состояний и вариантов исполнения кода. Более того, тесты, проверяющие «граничные» и «критические» значения остаются в большинстве случаев «за кадром». Поэтому сложные и редкие ошибки не выявляются юнитами.
2. Любые утверждения, что юниты экономят время, безосновательны, потому как юнит тесты не исключают дебага. А если сделан пошаговый дебаг, большого смысла в юнит тестах я не вижу. Все говорят об эффективности и правильности юнитов, но никто до сих пор наглядно так и не доказал это.
3. Заранее просчитать результат выполнения сложной функции не представляется возможным, не выполнив ее перед этим. Только пошаговый контроль в дебаге сможет выявить, что вычисленный результат верен. Если юнит не сработал, так или иначе придется дебагить.
4. Юнит тесты сложны в поддержке. Код меняется по мере разработки — тонны юнитов летят в корзину. Если Вы делаете одно простое изменение в коде, Вам нужно перелопатить десяток тестов.
Безусловная полезность юнитов и TDD является в том, что самого начала заставляет быдлокодеров заботиться о компонентной модели кода и декомпозиции функционала.
Ответ очевиден. Все дело в API. GDI32 использует пиксельную привязку к координатам. Поэтому и позиционировать по строке, например курсор, можно только в целых числах. Современные графические библиотеки, в том числе и GDI+, уже давно используют дробную арифметику, но видимо всплыли проблемы с совместимостью со старыми API, либо GDI+ просто лежит леером поверх старого GDI32.
Дело в том, что на подобных сайтах есть категория дрочеров, их меньше 1%, которые засирают анкеты девушек 99% месседжей. Они сидят днями и ждут появления новых анкет, чтобы написать «Привет, крошка, как дела!». В итоге прочитав в первые пару дней 200 подобных сообщений, девушка устает и теряет всякую надежду.
???
if ( «OK».equals( str ) )…
вместо
if ( str != null && str.equals( «OK» ) )…
Если str == null, NPE не выскочит, а условие обработается корректно.
«Покемонные» эксепшны тоже необходимы, когда при отлове любого эксепшна нужно сначала выполнить общий кусок кода, а затем частные действия.
Если хотите быть таким креативным, сделайте кнопку «Х… як!» — пользователю будет интуитивно понятно, а заодно и повеселит.
Доска глянцевая, в светлом классе единственное, что будет видно — блики от окон.
На самом деле выводы автора не совсем верны. Например «с возрастом меньше курят». График говорит, лишь о том, что молодежь курит больше. Но совсем не обязательно (и скорей всего нет), что с возрастом они бросят курить.
В своем проекте я использовал GWT Comet. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.
Один реализуется поверх другого. Отличие примерно такое же как между JavaScript и JQuery. Но цель у них одна — дуплексный обмен данными в реальном времени. Использовать голый TCP в окружении браузера проблематично — это не юникс, и с тредами здесь проблемы. Поэтому добавили асинхронный JavaScript API для пакетного обмена.
Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.