Подождите гнать, товарищи. Есть такая вещь как закон, и действия любых чиновников обязаны быть в соответствие с ним. Так вот, в данном случае обязан быть истец, который утверждает, что вы нарушаете его права нелицензионным использованием его продуктов. В случае с Windows - это ясное дело Microsoft. Но тем не менее, Вы можете пользовать у себя свободно любую софтину, и ни один чиновник не может применить административные меры по отношению к Вам до тех пор, пока не объявляется ее правообладатель, который будет требовать справедливости. Так что то, что стоит на ваших серверах - Linux или ОС Вася Пупкин (а представьте себе, что это ваша внутренняя разработка - на нее, что тоже себе лицензию выписывать?) не должно волновать никакого чиновника. Хватит того, что это неВиндовс. А то, что Вы своим использованием нарушаете чьи-то права - это должен доказывать он, а не вы (согласно основам римского права).
P.S. Я не юрист, поэтому очень приветствуется любой коментарий профессионала.
В реальных формах валидация инпута намного сложнее. В некоторых случаях требуется объяснить пользователю почему ввод неверный, например если в поле никнейма введены символы !"·$%&/($, тогда можно показать сообщение о допустимых символах в этом поле.
Зачастую доза лекарства назначаются врачем в зависимости от комплекции и других параметров пациента, так что упаковки должны варьироваться с таблетками разного веса. А вообще, зачет за юзабилити.
Сразу вопрос - а как дело обстоит с write-back кешированием? Возможны варианты ответов:
1. А нэту. Все жестко пишем физически на диск.
2. Данные теряются при сбое. На свой страх и риск.
3. При сбое данные сохраняются во флеш-памяти, и будут скинуты физически на диск после перезагрузки.
Да, да. Если тебя хотят грабануть по дорожке, или не дай бог завалить - всегда будут знать где и когда это удобней всего сделать. Писалось уже, что Вконтакте.ру используется для поиска должников...
Не совсем согласен по поводу Java2ME. Приложения отлично совместимы между разными аппаратами. Все работает согласно поддерживаемой устройством спецификации (MIDP, CLDC).
JavaME действительно сворачивается, но сворачивается в пользу стандартной спецификации JavaSE. Sun считает, что мобильные устройства стали достаточно мощными, чтобы запускать стандарную VM. Между тем спецификация ME никуда не денется, а останется для устройств с "ограниченными возможностями" (limited device). Поддержка стандарта ME планируется еще 10 лет.
AWT/Swing на линухе сильно тормозит (особенно если включить Compiz). Поэтому все IDE на свинге (IDEA, Netbeans) будут также тормозить. Это единственный и очень важный момент почему я хочу перейти на мак.
Интересует мнение, через сколько времени нужно обновлять жесткие диски на домашнем компе, чтобы минимизировать вероятность потери данных? У меня диску 3 года, может пора?
Это понятно, что эксперты не сомневаются. Им за это деньги платят. Просто если сравнивать реальные задачи, которые успешно решаются с самых первых времен, как только появился компьютер, то данные концепции не приносят абсолютно никакой экономической, стратегической или политической выгоды. А сложность способов решения одной и той же задачи не ограничена сверху. Если посмотреть в корень, то вся эта интеграция это не более чем реализация протокола связи и конвертер форматов. Хорошо, конечно, все унифицировать в рамках одной компании, типа интерфейсы, форматы, и т.д. но продается совсем не это. Продается решение типа "нарисуйте мышкой программу" или "нарисуйте мышкой вебсервис".
IBM действительно в последнее время начала активно заниматься консалтингом, однако занятно то, что "специалисты" не числятся в их штате, а набраны с улицы. Дешево и сердито.
Извините наболело. Сразу просьба не сильно минусовать. Господа, я работаю в сфере так называемых "бизнес интеграций" уже достаточно долгое время. Используем продукты пресловутого IBM (IBM Interchange Server, MQ Workflow, Websphere Integration Broker, Websphere Process Server, Websphere MQ, DB2, etc...). Отличительной чертой этих коммерческих продуктов от других является то, что они глючат и валятся на каждом шагу и несовместимы друг с другом даже в рамках одной ветки. Продукты IBM в сфере интеграции - самые низкосортные, дорогие и безобразные. Техническая поддержка отвратительная, документации нет (точнее есть горстка талмудов, в которых одна вода и в каждом предложении 7 раз повторяется слово Business). Решения иногда просто поражают своим абсурдом. Вы когда-нибудь пробовали установить скажем, DB2 на комп из стандартной комплектации? Встанет тока через пару дней танцев с бубном! Для сравнения, Microsoft SQL Server устанавливался на любой тачке за пару минут без всяких проблем. А настраивали когда-нибудь коннектор к SAP-у (единственная вещь, ради которой вся эта хрень используется). Более того, чтобы запустить все это барахло локально на тачке в режиме дебага нужно 16-32 GB оперативки. А Remote Monitoring/Debagging как например в SAP-е у них вообще не предусмотрено.
Далее, могу с уверенностью сказать, что предлагаемые решения типа SOA, SCA, BPEL, Business Objects, XML/XSD, MQ, ESB это все дым и пыль в глаза, дабы сорвать нехилый бюджет с проекта. Клиенту запаривают паравоз из рудиментарных глючных продуктов, которые без технической поддержки самого IBM никогда не заработают, заставляют нанимать штат дебилов в 10 раз превышающий реальные потребности (это называется методология работы), каждому на десктоп лицензию на средства разработки, впаривают курсы обучения и т.д. и т.п. В итоге ничего не работает, сроки срываются, а виноватых как бы нет.
Дабы не быть голословным, в одной стране S есть два крупных телекоммуникационных оператора J и T. У обеих компаний стояла похожая задача интегрировать системы CRM, инвентарий, сервис-активатор, мониторинг, и еще несколько, а также обеспечить выполнение бизнес процессов в workflow. В компании J два наших соотечественника за год сделали с нуля полнофункциональную систему "под ключ", используя платформу Java и open-source решения. Бюджет проекта был X. В компании T (которая является монополистом на рынке связи в стране S, а также на континенте L, и достаточно широко развита в содружестве E) 80 человек делали ту же работу, используя продукты IBM. За три года израсходован бюджет в 100X и не получено ни одной даже сырой функциональной версии. Энтропия проекта сейчас такова, что он уже никем не контролируется и смысла его продолжать уже нет никакого.
Такими темпами IBM погубит вест крупный бизнес, а на ее место придет Microsoft с качественными(!), но пропиетарными продуктами. Слава богу пока есть Opensource и Sun! Однако департамент по окучке менеджеров проектов у IBM работает безотказно.
> Кстати, изобретением уже шибко заинтересовалась армия США
С этого и надо было начинать. Мощный ЭМ импульс (как например при взрыве ядерной бомбы) способен вывести из строя всю электронику в округе. Соответственно военным нужна новая элементарная база, не подверженная ЭМ излучениям.
Кстати, я где-то слышал, что у нас тоже разрабатывалась механическая элементарная база, только основанная на пневмоклапанах. Кто-нибудь подтвердит, или это мулька?
Со временем переключения пикселя 6мс частота может быть до 166Гц.
2Latin_13: "недеструктивные" алгоритмы сжатия не могут гарантировать любое заданное наперед сжатие, а это принципиально, если проектируешь ограничить канал. Пиковая нагрузка может превысить ширину канала. Если только скипать кадры...
У моего соседа по работе есть штука прикольнее - пропеллер на гибком шланге, воткнутый в USB-порт. Абсолютно бесшумный, генерит владельцу ветер, а окружающим зависть.
Готов подписаться под каждым пунктом! Испытанно на собственной шкуре. Осмелюсь добавить еще пару пунтков:
21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.
22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.
23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.
24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.
25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.
26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.
> Я думаю, что вопрос о приятии модели открытого ПО в том, что никто на самом деле не может спроектировать сложную систему. Это просто противоречит естественному ходу вещей: люди не насколько умны, ни один человек. Модель же открытого ПО позволяет не проектировать вещи, а позволяет им эволюционировать, проходя через преграды потребительского рынка. Таким образом, конечный результат постоянно улучшается.
В проектировании операционной системы нет ничего экстраординарного. Более того, скажу, в любом техническом проекте, даже не связанным с программированием, есть человек, который знает ВСЕ (главный иженер, архитектор, etc). Поэтому сложность любого проекта как правило ограничена возможностями данного человека.
Насчет линукса я более категоричен, хоть сам его использую. Большинство идей, имплементированных в линухе - это коммерческие идеи 5-10 летней давности. Создается впечатление, что открытое ПО несется в догонку за компаниями-производителями ПО, крича на лету "А мы тоже умеем! А у нас это тоже есть!" Вопреки сказанному развитие свободного ПО идет гораздо медленней, поскольку сообщество опен-сорс намного более инертное к принятию инноваций, нежели любая коммерческая компания.
Хоть я недолюбливаю PHP, но аффтару Респект!
Сразу предложу материал для дальнейшего развития фреймворка:
1. Желательно вынести конфигурацию сайта и page-flow за пределы кода в конфигурационный файл и немного отделить декларативную часть от имплементации.
2. Весчь, которой не хватает в Struts и которая есть в JSF: events. Отличаются от экшнов тем, что только меняют состояние активной страницы, но при этом не осуществляют перехода на другую и не делают никаких значимых действий. Например если у меня на странице есть компонент типа дерева, с динамической подгрузкой scopes, открытие юзером поддерева делает рефреш страницы и посылает контроллеру событие. Контроллер вытаскивает из модели необходимые для поддерева данные и страница рендерится заново с новыми изменениями.
3. Помимо View ввести понятие компонента, который имеет свой рендерер, контроллер и модель, и преставляет собой отдельный (reusable) элемент интерфейса (но более сложный, чем стандартные html). Одни и те же компоненты могут использоваться в различных Views. Экшн-контроллер может принимать события от компонента, а также ессно обмениваться с ним данными. Изменение состояния компонента может осуществляться либо через JavaScript, либо через refresh страницы, либо используя Ajax.
4. Ajax-интеграция для компонентов.
5. Библиотека стандартных компонентов (элементов интерфейса) была бы только плюсом.
Хороший пример подобной библиотеки лежит здесь: http://myfaces.apache.org/tomahawk/
да никак! сколько не трать - не окупится. если за тобой не стоит никакой крупного инвестора, желающего бескорыстно потратить пару сотен тысяч (поправка на европу) в обмен на свое лого на сайте, проект можно закапывать не начиная. если же инвестор найдется, на его денежки можно спокойно жить годик и поднять проект в техническом смысле. инвестору можешь писАть любой бизнес план и ставить любые цифры - его это не сильно интересует. дальнейшая судьба проекта: обкатанную технологию можно продать в другие крупные порталы. но все-равно - интернет проект живет, пока его спонсируют. очень немногие проекты самостоятельно выходят на нулевой уровень (то есть расходы = доходам), и совсем единицы - на самообеспечение (доход = расходы+зарплата программерам+вложения).
P.S. Я не юрист, поэтому очень приветствуется любой коментарий профессионала.
1. А нэту. Все жестко пишем физически на диск.
2. Данные теряются при сбое. На свой страх и риск.
3. При сбое данные сохраняются во флеш-памяти, и будут скинуты физически на диск после перезагрузки.
JavaME действительно сворачивается, но сворачивается в пользу стандартной спецификации JavaSE. Sun считает, что мобильные устройства стали достаточно мощными, чтобы запускать стандарную VM. Между тем спецификация ME никуда не денется, а останется для устройств с "ограниченными возможностями" (limited device). Поддержка стандарта ME планируется еще 10 лет.
IBM действительно в последнее время начала активно заниматься консалтингом, однако занятно то, что "специалисты" не числятся в их штате, а набраны с улицы. Дешево и сердито.
Далее, могу с уверенностью сказать, что предлагаемые решения типа SOA, SCA, BPEL, Business Objects, XML/XSD, MQ, ESB это все дым и пыль в глаза, дабы сорвать нехилый бюджет с проекта. Клиенту запаривают паравоз из рудиментарных глючных продуктов, которые без технической поддержки самого IBM никогда не заработают, заставляют нанимать штат дебилов в 10 раз превышающий реальные потребности (это называется методология работы), каждому на десктоп лицензию на средства разработки, впаривают курсы обучения и т.д. и т.п. В итоге ничего не работает, сроки срываются, а виноватых как бы нет.
Дабы не быть голословным, в одной стране S есть два крупных телекоммуникационных оператора J и T. У обеих компаний стояла похожая задача интегрировать системы CRM, инвентарий, сервис-активатор, мониторинг, и еще несколько, а также обеспечить выполнение бизнес процессов в workflow. В компании J два наших соотечественника за год сделали с нуля полнофункциональную систему "под ключ", используя платформу Java и open-source решения. Бюджет проекта был X. В компании T (которая является монополистом на рынке связи в стране S, а также на континенте L, и достаточно широко развита в содружестве E) 80 человек делали ту же работу, используя продукты IBM. За три года израсходован бюджет в 100X и не получено ни одной даже сырой функциональной версии. Энтропия проекта сейчас такова, что он уже никем не контролируется и смысла его продолжать уже нет никакого.
Такими темпами IBM погубит вест крупный бизнес, а на ее место придет Microsoft с качественными(!), но пропиетарными продуктами. Слава богу пока есть Opensource и Sun! Однако департамент по окучке менеджеров проектов у IBM работает безотказно.
С этого и надо было начинать. Мощный ЭМ импульс (как например при взрыве ядерной бомбы) способен вывести из строя всю электронику в округе. Соответственно военным нужна новая элементарная база, не подверженная ЭМ излучениям.
Кстати, я где-то слышал, что у нас тоже разрабатывалась механическая элементарная база, только основанная на пневмоклапанах. Кто-нибудь подтвердит, или это мулька?
2Latin_13: "недеструктивные" алгоритмы сжатия не могут гарантировать любое заданное наперед сжатие, а это принципиально, если проектируешь ограничить канал. Пиковая нагрузка может превысить ширину канала. Если только скипать кадры...
21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.
22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.
23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.
24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.
25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.
26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.
Кто еще что добавит?
> Я думаю, что вопрос о приятии модели открытого ПО в том, что никто на самом деле не может спроектировать сложную систему. Это просто противоречит естественному ходу вещей: люди не насколько умны, ни один человек. Модель же открытого ПО позволяет не проектировать вещи, а позволяет им эволюционировать, проходя через преграды потребительского рынка. Таким образом, конечный результат постоянно улучшается.
В проектировании операционной системы нет ничего экстраординарного. Более того, скажу, в любом техническом проекте, даже не связанным с программированием, есть человек, который знает ВСЕ (главный иженер, архитектор, etc). Поэтому сложность любого проекта как правило ограничена возможностями данного человека.
Насчет линукса я более категоричен, хоть сам его использую. Большинство идей, имплементированных в линухе - это коммерческие идеи 5-10 летней давности. Создается впечатление, что открытое ПО несется в догонку за компаниями-производителями ПО, крича на лету "А мы тоже умеем! А у нас это тоже есть!" Вопреки сказанному развитие свободного ПО идет гораздо медленней, поскольку сообщество опен-сорс намного более инертное к принятию инноваций, нежели любая коммерческая компания.
Сразу предложу материал для дальнейшего развития фреймворка:
1. Желательно вынести конфигурацию сайта и page-flow за пределы кода в конфигурационный файл и немного отделить декларативную часть от имплементации.
2. Весчь, которой не хватает в Struts и которая есть в JSF: events. Отличаются от экшнов тем, что только меняют состояние активной страницы, но при этом не осуществляют перехода на другую и не делают никаких значимых действий. Например если у меня на странице есть компонент типа дерева, с динамической подгрузкой scopes, открытие юзером поддерева делает рефреш страницы и посылает контроллеру событие. Контроллер вытаскивает из модели необходимые для поддерева данные и страница рендерится заново с новыми изменениями.
3. Помимо View ввести понятие компонента, который имеет свой рендерер, контроллер и модель, и преставляет собой отдельный (reusable) элемент интерфейса (но более сложный, чем стандартные html). Одни и те же компоненты могут использоваться в различных Views. Экшн-контроллер может принимать события от компонента, а также ессно обмениваться с ним данными. Изменение состояния компонента может осуществляться либо через JavaScript, либо через refresh страницы, либо используя Ajax.
4. Ajax-интеграция для компонентов.
5. Библиотека стандартных компонентов (элементов интерфейса) была бы только плюсом.
Хороший пример подобной библиотеки лежит здесь: http://myfaces.apache.org/tomahawk/