нет. У нас направление существенно пропиетарное. Более того, мы только сейчас начали задумываться о том, чтобы все это как-то людям продвигать. Скорее всего на условиях SaaS. Как раз под это последнее перелопачивание учинили.
Теперь сам движок вроде как вполне на уровне — осталась самая малость — заваять и прикрутить к нему божеские удобные интерфейсы и навешать рюшечек типа CRM. И можно двигать в массы.
Вообще говоря, у нас есть некие мысли о том, чтобы какой-то кусок системы загнать в C и раздавать как PHP-шное расширение. Но это пока далекие планы.
У вас все впререди)))). Мы эту систему с 1999 года разрабатываем. Последние года 2 — время переоптимизаций. Типа сокращаем требуемую для вывода 10К строк из таблицы память до объема информации в этих строках, выводим главную страницу портала одним SQL простым запросом и т.д.
Ну и время разработки прототипа сайта (без верстки и наполнения) — до пары-тройки часов. Причем сайт предполагается весь из себя нестандартный. Типа собрали, посмотрели, поменяли при необходимости чего-то, еще раз собрали. И так далее.
А там нет никакого геморроя. Там все прозрачно.
Есть интерфейс для создания класса. Из этого интерфейса все необходимое генерится на автомате.
строк 50 на C (в переопределенных ltree и int[]), килобайт 60 на PHP, и килобайтов 5 на PL/PGSQL — а все прочее автоматически. Нажатием кнопки «хочу CMS»)))
За совет спасибо. Я это все смотрел в свое время. К сожалению, у меня часто проскакивают модифицированные по сравнению со стандартными типы данных. Разбираться в том, как себя поведет чужой фреймворк при их разборе — занятие не самое благодарное. Да и куда проще, IMHO, всяческие сложные типы разбирать внутри PostgreSQL, а не тащить их в PHP и парсить там. Проще и быстрее.
И, кстати, переименование столбца вообще говоря во VIEW транслируется корректно (на знаю, правда, транслируется ли в условие, а вот в столбцы view — легко)
Ну, собственно я это и имел в виду. Просто сам сижу сейчас с похожей фиговиной (собственно на днях ее высидел)))
Возможно, у меня ситуация немного другая. У меня при создании CMS генерятся таблицы для этой CMS. При этом состав столбцов вообще говоря у разных CMS различается. И, в процессе работы над сайтом может меняться дальше.
То есть типа возникла необходимость добавить классу свойство — нужно поменять табличку. Соответственно, prepared statment нужно будет менять, причем получить внутренний порядок столбцов таблицы из PHP корректно не получается (оно там может случайным образом совпасть, а может и не совпасть). Если порядок столбцов не совпадет, prepared statment работать не будет. А когда мы создаем view, у нас эта проблема исчезает.
Система, в которой таблицы меняются, конечно, право на существование имеет. Более того — часто сильно облегчает жизнь (разумеется, при правильном подходе). Но вот в чем вопрос — мне показалось, или нет — в вашем этом самом велосипеде VIEW куда-то испарился. Тогда в чем цимес? Не проще ли будет тогда просто запрос генерить, без SQL-фильтра?
Или идея в том, чтобы вместо VIEW создавать фильтры?
И immutable меня там смущает несколько — вообще говоря, согласно мануалу оно применяется в контексте строки, и если у вас случился апдейт таблицы, функция immutable быть перестает (впрочем, я замечал и иное поведение, с чем оно связано, понять мне пока сложно).
А вообще зря вы от VIEW уходите. IMHO, единственный 100%-корректный способ делать prepared statement для меняющихся таблиц именно на VIEW (правда, при создании тогда следует прямо перечислять все требуемые столбцы в нужном порядке).
Нам немного проще — у нас CMS генерится для каждого проекта, посему, вообще говоря, CMS одного сайта отличается от CMS другого и является самостоятельным продуктом. Ну и стоимость лицензии с отчуждением авторских прав, против обычной, задрана раза в четыре.
Впрочем, все это не освобождает от «определенных формулировок в договоре»))))
Пока писал пост, появилось несколько аналогичного содержания.
Видимо от тех, кто с госстурктурами работал.
Смысл всех примерно одинаковый — «мышки плакали, кололись, но продолжали есть кактус».
То есть, в постах в основном про то, что плакали и кололись.
Но, поскольку гос. сайты продолжают появляться, значит кактус жрать все-таки можно, причем, скорее всего, даже с прибылью.
Вероятно, все, выссказывавшиеся выше, почти правы. Общий смысл комментов — это мог бы сделать и я. Дополнительный смысл — за куда меньшие деньги. С первым утверждением я слонен соглашаться. Со вторым — скорее соглашаться. Правда, с некоторыми оговорками.
1) Чтобы сделать этот сайт, нужно внести перед конкурсом 225000 рублей на обеспечение конкурсной заявки.
2) Если вдруг конкурс вы выиграли, вам нужно внести на обеспечение работ еще 1350000 рублей (30% от первоначальной стоимости аукциона). Поскольку, вы этот аукцион выиграли, а ставки шли на понижение, часть этой суммы вам вернут в качестве предоплаты за работы. В данном случае — 1140000 рублей. Правда, вернут не то, чтобы совсем сразу. Так что надо быть готовым к кредитованию государства. Скорее всего — до 25 — 31 декабря какого-нибудь очередного года.
3) Нужно согласовать ТЗ со всеми отделениями ПФР ну и с его штаб-квартирой. Причем, ТЗ должно быть написано по ГОСТу. В среднем, приобретя некоторый опыт в написании таких ТЗ, можно это сделать (если предположить, что все согласования проведены) примерно месяца за полтора-два. Или меньше, но тогда вам нужен какой-то человек у Заказчика, который будет гарантировать, что это ТЗ никто кроме него читать не будет. Что окажется дешевле, в данном случае, зависит от вашей ситуации
4) Для сайта нужен движок.
Причем, бесплатные движки не покатят.
Покупные, вообще говоря, тоже.
Дело в том, что у госструктур есть пренеприятнейшая особенность — они хотят движок со всеми авторскими и смежными правами.
Еще, как правило, с годом поддержки, но это уже мелочи.
Еще с протоколом испытаний движка по ГОСТу (это тоже где-то пара недель работы, если сами испытания не проводить, а только правильно оформить протокол).
5) Для сайта нужно собрать информацию со всех подразделений, обработать ее, разместить на сайте и, затем, утвердить. В процессе утверждения, между различными подразделениями возникают всяческие трения, кто-то замечает, что информации он мог бы дать больше и, рано или поздно (скорее поздно) информацию эту вам передает, после чего согласования идут по новому кругу и так далее.
Да, координация согласований, скорее всего ляжет на вас.
6)Сбор информации, согласование ТЗ устранение трений между подразделениями, может потребовать вашего (либо вашего представителя) личного присутствия. Командировочные расходы, разумеется, не компенсируются.
Собственно, я перечислил действительно важные для Заказчика пункты.
Есть еще дизайн, верстка, собственно возможности движка, обработка текстов и графики и все остальное, что для большинства здесь собравшихся и подразумевается под термином «создание сайта». То самое, что и стоит от 3 до 10 килобаксов.
Все это заказчика практически не волнует. Он не считает это важными аспектами, посему уделяет им минимум своего внимания. ТО есть, если повезет, затраты непосредственно на разработку составят эти самые 3 — 10 килодолларов. Если не повезет (а может и не повезти, поскольку до сборки готового сайта этим мелочам внимания особого не уделяется — хорошо, если дизайн удастся согласовать перед сборкой сайта), придется сайт переделать, Поскольку, определенный опыт у вас уже будет, себестоимость переделанного сайта будет ниже.
Вот как-то так.
Кто-то может посчитать 3.8 лимона демпингом, кто-то — запредельной оплатой. Зависит, скорее всего, от личных потребностей.
А защита от XSS у них на сайте и в самом деле дурная какая-то
Есть. pg_send_query и другие функции для асинхронных запросов. Правда, глубинное понимание того, как они работают, приходит, скорее, не после чтения мануала, но на собственном опыте. Впрочем, иногда оно того стоит
Можно посмотреть в настройках сети браузеров. Ну и пролечиться всем подряд. Мне как-то в похожей ситуации помогла комбинация (последовательная) Norton, Avast, Kaspersky,Nod32,Avast,Nod32,Avast.
Если не поможет — тогда смело считайте, что лично на вас ополчился лично Дуров (или лично кто-нибудь еще).
Но я голосую за вирус.
Пригляделся — а автор топика — это же вы. Сорри, за обращение в третьем лице. Глаз замылился. Я сейчас как раз пишу для нашего сайта текст про внешний контроль исполнения, причем примерно на ту же тему, что и ваш топик, посему, видимо, мысли где-то «за витали».
да нет — планирование вроде как на уровне. То есть со скидкой на переоценку. Вернее — в данном случае — со 100% наценкой. Менеджмент прихрамывал — то есть не замечал вовремя увлечения программистов улучшениями кода и архитектуры — а когда замечал, проект уже сильно отличался от изначального ТЗ. Отличался в лучшую сторону, но вот беда — Заказчик, даже если он все понимает и ему само по себе идея нравится, иногда бывает поставлен в условия, что ему просто надо ехать. То есть он готов ехать и на жигулях, и на мерседесе. Мы ему изначально собирались жигули предоставить, а тут такая бодяга — вместо жигуля — мерседес. Но не совсем собранный. ТО есть водительское место отличное, и левое переднее колесо, а уж какой у него домкрат…
Можно было бы попинать на никчемность менеджера проекта (и мы, разумеется, пинали), но автор топика чуть шире мыслит. Ну я в след за ним пытаюсь.
У меня есть ощущение (во многом сформированное собственным опытом — сам грешен внесением изменений по ходу разработки), перфекционист всегда будет пытаться сделать лучше, чем спроектировано, тем самым внося разброд и шатания в работу всей команды.
P.S. Это ни в коем случае не означает, что перфекционисты не нужны. Просто надо уметь правильно их готовить. И одного менеджерского надзора может не хватить (не говоря уже о том, что если этот надзор окажется слишком плотным, велика вероятность перфекциониста потерять — он либо уйдет, либо махнет на все рукой и превратится в трудягу)
Спорно это все, IMHO. Возможно, мне в этом плане «везло» (везение всякий может понимать как ему заблагорассудится), но мне чаще попадались именно «IT-художники» (в терминологии автора топика), или IT-перфекционисты (в моей собственной терминологии). И именно они благополучно запарывали весьма перспективные проекты, пытаясь внедрить нечто, «прямо или косвенно приносящеет прибыль Заказчику».
Причем речь здесь не о неудачных попытках внедрения. Попытки, и, соответственно, внедрения, как раз, чаще всего оказывались успешными. А вот сроки напрочь срывались.
Возможно, идеальным был бы некий вариант XP, когда за компом сидело бы 2 человека — перфекционист, трудяга (термин опять же мой — соответствие с терминологией поста каждый может отыскать самостоятельно) и менеджер. Трудяга остужал бы перфекциониста, перфекционист пинал трудягу, а менеджер, в случае, если пинание увенчалось бы успехом, уточнял бы у Заказчика — а надо оно ему, или нет.
Впрочем, сдается, мое предложение тоже панацеей не является.
Местами полезный (с точки зрения объявлений и регистрации на встречи Russian Adobe Flash Platform User Group и если не обращать внимание на кучу абстрактного корпоративного пиара) блог флексиса
Авторское право возникает вне зависимости от документов. Оно возникает просто по факту авторства. Более того — исходя из сабжа, вопросов в авторстве также не возникает. Посему, тут дело уже на в авторских, а в смежных правах. Смежные права первоначально возникают у автора по тому самом факту авторства, а затем (это самое затем может оказаться весьма скоротечным — например, если вы разрабатываете ПО в конторе, в вашем трудовом договоре скорее всего зафиксирован факт автоматической передачи всех смежных прав этой самой конторе сразу по факту создания любого кода) могут быть переданы, платно или бесплатно, с условиями или без условий и т.д. Например, смежные права на Pure Open Source (типа Столлман) (воспроизведение, использование, модификация, использование в других продуктах, распространение) передаются при условии их дальнейшего свободного распространения и т.д.
Теперь внимание! В случае, если в лицензии прямо не было прямого указания на передачу определенных прав с перечислением этих прав, все права (и авторские, и смежные) сохраняются за автором. При этом вопрос оформления лицензии остается открытым — в общем случае годится все, начиная с устной договоренности. Более того — вопрос авторского права на программные продукты также не столь однозначен, как, например, на литературные произведения, фото и видео материалы.
А вообще, в данном случае, IMHO, если «Сайт довольно долго жил и развивался», и особых претензий к движку, видимо, не было, честно будет копирайт поставить. Если, при этом, движок «Хорошенько перелопа»чивался — поставить копирайт вроде «на основе такого-то».
Теперь сам движок вроде как вполне на уровне — осталась самая малость — заваять и прикрутить к нему божеские удобные интерфейсы и навешать рюшечек типа CRM. И можно двигать в массы.
Вообще говоря, у нас есть некие мысли о том, чтобы какой-то кусок системы загнать в C и раздавать как PHP-шное расширение. Но это пока далекие планы.
Ну и время разработки прототипа сайта (без верстки и наполнения) — до пары-тройки часов. Причем сайт предполагается весь из себя нестандартный. Типа собрали, посмотрели, поменяли при необходимости чего-то, еще раз собрали. И так далее.
Есть интерфейс для создания класса. Из этого интерфейса все необходимое генерится на автомате.
строк 50 на C (в переопределенных ltree и int[]), килобайт 60 на PHP, и килобайтов 5 на PL/PGSQL — а все прочее автоматически. Нажатием кнопки «хочу CMS»)))
За совет спасибо. Я это все смотрел в свое время. К сожалению, у меня часто проскакивают модифицированные по сравнению со стандартными типы данных. Разбираться в том, как себя поведет чужой фреймворк при их разборе — занятие не самое благодарное. Да и куда проще, IMHO, всяческие сложные типы разбирать внутри PostgreSQL, а не тащить их в PHP и парсить там. Проще и быстрее.
Возможно, у меня ситуация немного другая. У меня при создании CMS генерятся таблицы для этой CMS. При этом состав столбцов вообще говоря у разных CMS различается. И, в процессе работы над сайтом может меняться дальше.
То есть типа возникла необходимость добавить классу свойство — нужно поменять табличку. Соответственно, prepared statment нужно будет менять, причем получить внутренний порядок столбцов таблицы из PHP корректно не получается (оно там может случайным образом совпасть, а может и не совпасть). Если порядок столбцов не совпадет, prepared statment работать не будет. А когда мы создаем view, у нас эта проблема исчезает.
Или идея в том, чтобы вместо VIEW создавать фильтры?
И immutable меня там смущает несколько — вообще говоря, согласно мануалу оно применяется в контексте строки, и если у вас случился апдейт таблицы, функция immutable быть перестает (впрочем, я замечал и иное поведение, с чем оно связано, понять мне пока сложно).
А вообще зря вы от VIEW уходите. IMHO, единственный 100%-корректный способ делать prepared statement для меняющихся таблиц именно на VIEW (правда, при создании тогда следует прямо перечислять все требуемые столбцы в нужном порядке).
Хотя, кактус все-таки дюже колючий)))
Впрочем, все это не освобождает от «определенных формулировок в договоре»))))
Видимо от тех, кто с госстурктурами работал.
Смысл всех примерно одинаковый — «мышки плакали, кололись, но продолжали есть кактус».
То есть, в постах в основном про то, что плакали и кололись.
Но, поскольку гос. сайты продолжают появляться, значит кактус жрать все-таки можно, причем, скорее всего, даже с прибылью.
1) Чтобы сделать этот сайт, нужно внести перед конкурсом 225000 рублей на обеспечение конкурсной заявки.
2) Если вдруг конкурс вы выиграли, вам нужно внести на обеспечение работ еще 1350000 рублей (30% от первоначальной стоимости аукциона). Поскольку, вы этот аукцион выиграли, а ставки шли на понижение, часть этой суммы вам вернут в качестве предоплаты за работы. В данном случае — 1140000 рублей. Правда, вернут не то, чтобы совсем сразу. Так что надо быть готовым к кредитованию государства. Скорее всего — до 25 — 31 декабря какого-нибудь очередного года.
3) Нужно согласовать ТЗ со всеми отделениями ПФР ну и с его штаб-квартирой. Причем, ТЗ должно быть написано по ГОСТу. В среднем, приобретя некоторый опыт в написании таких ТЗ, можно это сделать (если предположить, что все согласования проведены) примерно месяца за полтора-два. Или меньше, но тогда вам нужен какой-то человек у Заказчика, который будет гарантировать, что это ТЗ никто кроме него читать не будет. Что окажется дешевле, в данном случае, зависит от вашей ситуации
4) Для сайта нужен движок.
Причем, бесплатные движки не покатят.
Покупные, вообще говоря, тоже.
Дело в том, что у госструктур есть пренеприятнейшая особенность — они хотят движок со всеми авторскими и смежными правами.
Еще, как правило, с годом поддержки, но это уже мелочи.
Еще с протоколом испытаний движка по ГОСТу (это тоже где-то пара недель работы, если сами испытания не проводить, а только правильно оформить протокол).
5) Для сайта нужно собрать информацию со всех подразделений, обработать ее, разместить на сайте и, затем, утвердить. В процессе утверждения, между различными подразделениями возникают всяческие трения, кто-то замечает, что информации он мог бы дать больше и, рано или поздно (скорее поздно) информацию эту вам передает, после чего согласования идут по новому кругу и так далее.
Да, координация согласований, скорее всего ляжет на вас.
6)Сбор информации, согласование ТЗ устранение трений между подразделениями, может потребовать вашего (либо вашего представителя) личного присутствия. Командировочные расходы, разумеется, не компенсируются.
Собственно, я перечислил действительно важные для Заказчика пункты.
Есть еще дизайн, верстка, собственно возможности движка, обработка текстов и графики и все остальное, что для большинства здесь собравшихся и подразумевается под термином «создание сайта». То самое, что и стоит от 3 до 10 килобаксов.
Все это заказчика практически не волнует. Он не считает это важными аспектами, посему уделяет им минимум своего внимания. ТО есть, если повезет, затраты непосредственно на разработку составят эти самые 3 — 10 килодолларов. Если не повезет (а может и не повезти, поскольку до сборки готового сайта этим мелочам внимания особого не уделяется — хорошо, если дизайн удастся согласовать перед сборкой сайта), придется сайт переделать, Поскольку, определенный опыт у вас уже будет, себестоимость переделанного сайта будет ниже.
Вот как-то так.
Кто-то может посчитать 3.8 лимона демпингом, кто-то — запредельной оплатой. Зависит, скорее всего, от личных потребностей.
А защита от XSS у них на сайте и в самом деле дурная какая-то
Если не поможет — тогда смело считайте, что лично на вас ополчился лично Дуров (или лично кто-нибудь еще).
Но я голосую за вирус.
Можно было бы попинать на никчемность менеджера проекта (и мы, разумеется, пинали), но автор топика чуть шире мыслит. Ну я в след за ним пытаюсь.
У меня есть ощущение (во многом сформированное собственным опытом — сам грешен внесением изменений по ходу разработки), перфекционист всегда будет пытаться сделать лучше, чем спроектировано, тем самым внося разброд и шатания в работу всей команды.
P.S. Это ни в коем случае не означает, что перфекционисты не нужны. Просто надо уметь правильно их готовить. И одного менеджерского надзора может не хватить (не говоря уже о том, что если этот надзор окажется слишком плотным, велика вероятность перфекциониста потерять — он либо уйдет, либо махнет на все рукой и превратится в трудягу)
Причем речь здесь не о неудачных попытках внедрения. Попытки, и, соответственно, внедрения, как раз, чаще всего оказывались успешными. А вот сроки напрочь срывались.
Возможно, идеальным был бы некий вариант XP, когда за компом сидело бы 2 человека — перфекционист, трудяга (термин опять же мой — соответствие с терминологией поста каждый может отыскать самостоятельно) и менеджер. Трудяга остужал бы перфекциониста, перфекционист пинал трудягу, а менеджер, в случае, если пинание увенчалось бы успехом, уточнял бы у Заказчика — а надо оно ему, или нет.
Впрочем, сдается, мое предложение тоже панацеей не является.
Теперь внимание! В случае, если в лицензии прямо не было прямого указания на передачу определенных прав с перечислением этих прав, все права (и авторские, и смежные) сохраняются за автором. При этом вопрос оформления лицензии остается открытым — в общем случае годится все, начиная с устной договоренности. Более того — вопрос авторского права на программные продукты также не столь однозначен, как, например, на литературные произведения, фото и видео материалы.
А вообще, в данном случае, IMHO, если «Сайт довольно долго жил и развивался», и особых претензий к движку, видимо, не было, честно будет копирайт поставить. Если, при этом, движок «Хорошенько перелопа»чивался — поставить копирайт вроде «на основе такого-то».
Спасибо за ссылку — посмотрю обязательно.