> Кстати, изобретением уже шибко заинтересовалась армия США
С этого и надо было начинать. Мощный ЭМ импульс (как например при взрыве ядерной бомбы) способен вывести из строя всю электронику в округе. Соответственно военным нужна новая элементарная база, не подверженная ЭМ излучениям.
Кстати, я где-то слышал, что у нас тоже разрабатывалась механическая элементарная база, только основанная на пневмоклапанах. Кто-нибудь подтвердит, или это мулька?
Со временем переключения пикселя 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/
да никак! сколько не трать - не окупится. если за тобой не стоит никакой крупного инвестора, желающего бескорыстно потратить пару сотен тысяч (поправка на европу) в обмен на свое лого на сайте, проект можно закапывать не начиная. если же инвестор найдется, на его денежки можно спокойно жить годик и поднять проект в техническом смысле. инвестору можешь писАть любой бизнес план и ставить любые цифры - его это не сильно интересует. дальнейшая судьба проекта: обкатанную технологию можно продать в другие крупные порталы. но все-равно - интернет проект живет, пока его спонсируют. очень немногие проекты самостоятельно выходят на нулевой уровень (то есть расходы = доходам), и совсем единицы - на самообеспечение (доход = расходы+зарплата программерам+вложения).
Господа, не буду оригинален, но пора на свалку языки, допускающие подобное.
Пока все нормальные языки двигались в сторону контроля типов и строгих конструкций, скриптовые языки всегда пытались услужить программистам, убирая "ненужную" декларативную писанину. Использовать в веб среде язык, не делающий существенного различия между кодом и данными и допускающий динамический code-injection просто безумие. Поэтому любой php скрипт по дефолту остается дырявым, пока не доказано обратное. Я призываю всех обратить внимание в сторону Java EE: JSP/JSTL и фреймворков типа JSF.
Естественно сайт должен быть уже раскручен. Политика оплаты может быть очень гибкая. Поначалу нужно ввести дополнительные сервисы, доступные только после оплаты. Затем потихоньку урезать халяву до полного read-only. С одной стороны бесплатники ворчат недовольством, а с другой - члены клуба особенно горды своими привилегиями.
Насчет инвайтов - мне вспоминается из моего детства сеть Фидо. Сисоп был в ответе за своих поинтов, иначе его могли лишить ноды. В сети существовала определенная иерархия, что помогало осуществлять контроль и эффективное модеиррование эх.
"Интеллигентная социальная сеть" - звучит гордо! ;)
Как сделать так, чтобы юзеры не гадили в каментах? По своему опыту скажу, что лучший способ (и похоже, единственное решение) - это закрытый платный клуб с небольшой квотой. Как правило люди, заплатившие квоту и являющиеся его членами, ведут себя пристойно. Кроме того, это гарантирует всегда присутствие людей со схожими интересами. Публичное же место никогда не сделать пристойным, сколько бы усилий админов, идейщиков и программистов ни прилагалось. Это факт, проверенный на достаточно крупных проектах.
Блин, господа, 21-й век на дворе, а до сих пор переполнения буфера и скрипт-инжекшн. Пора выкидывать на помойку старые технологии, позволяющие данное раздолбайство. Интересно, а существуют эксплоиты для Tomcat/JSP?
С этого и надо было начинать. Мощный ЭМ импульс (как например при взрыве ядерной бомбы) способен вывести из строя всю электронику в округе. Соответственно военным нужна новая элементарная база, не подверженная ЭМ излучениям.
Кстати, я где-то слышал, что у нас тоже разрабатывалась механическая элементарная база, только основанная на пневмоклапанах. Кто-нибудь подтвердит, или это мулька?
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/
Пока все нормальные языки двигались в сторону контроля типов и строгих конструкций, скриптовые языки всегда пытались услужить программистам, убирая "ненужную" декларативную писанину. Использовать в веб среде язык, не делающий существенного различия между кодом и данными и допускающий динамический code-injection просто безумие. Поэтому любой php скрипт по дефолту остается дырявым, пока не доказано обратное. Я призываю всех обратить внимание в сторону Java EE: JSP/JSTL и фреймворков типа JSF.
Насчет инвайтов - мне вспоминается из моего детства сеть Фидо. Сисоп был в ответе за своих поинтов, иначе его могли лишить ноды. В сети существовала определенная иерархия, что помогало осуществлять контроль и эффективное модеиррование эх.
Как сделать так, чтобы юзеры не гадили в каментах? По своему опыту скажу, что лучший способ (и похоже, единственное решение) - это закрытый платный клуб с небольшой квотой. Как правило люди, заплатившие квоту и являющиеся его членами, ведут себя пристойно. Кроме того, это гарантирует всегда присутствие людей со схожими интересами. Публичное же место никогда не сделать пристойным, сколько бы усилий админов, идейщиков и программистов ни прилагалось. Это факт, проверенный на достаточно крупных проектах.