И если уж такая пьянка, с вызовом данных из представления, то вместо этого порно - "{block action="Mod_Products.blockNewProducts" limit="10"}", можно было бы сделать так: {model="NewsBlock" view="News"}, т.е. указать какую модель данных выполнить и какое представление наложить на всю эту кашу
1) Касаемо интелектуальной собственности - это вопрос все равно размытый и особено не доказуемый, в частности к фрилансу, считается, что если ты своим трудом, что-то изменил, поменял, то это уже "твой интелектуальный труд" и пр.
2) Модель построения бизнеса\сервисов\инфраструктуры\бизнес моделй на основе ITIL - довольно таки интересная, но требует колосальных денег\трудо затрат, впрочем один из основателей (ну или же вернее сказать ведущих специалистов) ITIL давно призанл, что ITIL, хороша, но не является лучшей моделью, а лишь сборником готовых опробированных решений.
3) Прецеденты работы да, офисов понятия не имею.
Хочу так же отметить, что давно-давно, когда я делал свой бизнес, именна эта модель и была избранна NN людей по разным областям были объединены и работали, первый наш офис был, организован на базе юр. конторы, с которой был заключен договор о сотрудничестве(консультация и пр.), на основании чего мы и находились в офисе. Так же у нас были люди, которые не занимались "нашим" бизнесом 100% а выполняли подряды по желанию, при этом занимаясь своим фрилансом со своим графиком. Естественно наша цель была формирование ооо и последующее развитие бизнеса, но в любом случае у нас были "пассажиры", которые работали сами на себя и иногда получали подряды, чему-то учились мы у них, чему-то они у нас.
В москве довольно много фирм, у которых в свободных помещениях сидят фрилансеры, и работают каждый над своим проектом, частично уделяя время на работу над подрядом комании\человека, который предоставляет им помещение, списывая часть оплаты, за услуги. С юридической точки зрения, их оформляют в штат или же по контракту\договору, как консультантов или же работников по определенному вопросу, что в полной мере является правдой, и юридически легализует их присуствие в помещении, для правоохранительных органов. И такой вид "сожительства", вполне жизнеспособен.
Если вы хотите собраться вместе и делать общее дело, это уход в сторону бизнес образования.
Если вы хотите,собраться вместе и каждый занматься своим делом, это как раз coworking.
Не правращайте "новое", в давно изъеденое "старое", за неимением опыта.
С юридической точки зрения, есть "множество" решений этой формы совместного "проживания", это все можно уточнить у юристов, прежде четко поставив задачи и разграничив зоны ответственности.
С юридической точки зрени это называется товарищество.
С точки зрени украть\нагадить, с каждым соучастнеком подписывается договор.
В общем-то вя организацию делается по принципу обычного ООО, за исключением формы юридического лица.
Естественно у большинства фрилансеров, нету таковых навыков для организации, я думаю тут напомощь могут прийти знакомые, с опытом в организации подобных мероприятий.
Тезис о том, что ставиться ровно столько, сколько заказывал ложный.
Во-первых, существуют разные модели построения библиотек по одной из версий их 9 и в зависимости от модели, разная степень избыточных методов при инициализации.
Во-вторых, benchmark всему голова :D
Пример сценария:
Ты подключаешь "большой" файл, который тащит за собой небольшое кол-во файлов на "все" случаи жизни.
Ты подключаешь "маленький" файл, который представляет из себя "lego", в результате чего, при наращивании функционала, открывается все большее кол-во файлов и плодятся наследуемости\инкапсуляции и прочие шалости ооп.
Класс, обрабатывается целиком перед выполнением, как на ошибки, так на инициализацию расходуется системное время\память.
Вопрос к тому, что нет смысла использовать такие монстроедальные классы. От большего кол-ва ручек на двери, дверь открывать удобнее не станет.
Имхо всякие propel doctrine adodb - это некий концептуальный ивзрат из серии: "Фигасе я придумал".
В принципе "+", что изобретаете велосипед, а иначе он никогда не полетит :)
Концепт он как воздух - его можно гонять веками, без сырцов - это не более чем пиар.
В целом позновательно, есть пару замечаний\дополнений:
>>Дилемма стартапа
К сожалению это не дилемма, а нетчо большее. Тут есть несколько подводных камней:
1) идея
У вас появилась идея, которую вы развиваете, пытаясь сделать более "рентабельно" ( как для монетизации, так и для скажем "популяризации" вашего проекта ), в данном случае иногда наступает эффект второй системы, т.е. пока вы проектируете все в первый раз, у вас растет ком идей, которые хотелось бы реализовать и уже почти реализованы, и в итоге весь проект стал идейной помойкой.
2) время
Конкуренты не дремлют, да и у вас ограниченное время, невозможно "безразмерно" тратить свое и чужое время в никуда.
3) бюджет
В любом случае есть бюджет, даже если собралась команда энтузиастов, в конце концов, они захотя есть, пить, курить и отдохнуть, а деньги то откуда-то надо брать, и вот этот вот заработок будет отнимать время.
>>Считается (не знаю кем), что оптимальное число команды-создателей должно быть не больше 3.
Данная форма "совладельцев" наиболее оптимальна и устойчива, т.к. не дает части совладельцев устроить "мятеж", а все потому, что долевой перевес 1 голоса решает( это если в кратце ) + есть некоторые юридические заморочки, которые делают эту схему наиболее устойчивой при равном распределении голосов.
Из личного опыта скажу 50\50 бизнес очень нервное занятие и "непонимание" всего лишь одного партнера(50%) - наглухо задушит весь бизнесс.
Опять же есть разные виды долей, я помню только 2 типа:
1) это голос
2) это % с прибыли
И то и то можно урегулировать "уставом" компании, что крайне редко делается в стартапах и в малом бизнесе тоже.
Хочется добавить всего одну вещь, у любого проекта должен быть "Журнал", в котором должно быть описано все( в вольной форме ), почему сделали так а не так, почему решили идти по этому пути или выбрали эту структуру( архетектуру ) - поверьте, вы в конце концов забудите( в действительносте забудите, почему ведущий программист сказал, что надо делать так ), а почему же было так, и снова или же сталкнетесь с этой "граблей" или "профукаете" момент, когда кто-то эти грабли починит.
В общем докуметация + журнал проекта - это важно :)
p.s. Не судите строго, это моё ИМХО и мой личный опыт.
- вызывать контроллер из представления логически абсурдно
- пихать в контроллер "модельную" состовляющую - некрасиво
p.s. брызь читать внимательно: http://ru.wikipedia.org/wiki/Model-view-controller
p.s. могу прочесть несколько мантр в личке)
я вот скачал тут свежий кладр архивчик и самый интересный файл kladr.dbf у меня под линухом не экстрактится :(
единственный вопрос, надеюсь там с адресами?
Для каждой группы, нужен лидер, который будет и авторитетен для окружающих и способен решить организационные вопросы.
1) Касаемо интелектуальной собственности - это вопрос все равно размытый и особено не доказуемый, в частности к фрилансу, считается, что если ты своим трудом, что-то изменил, поменял, то это уже "твой интелектуальный труд" и пр.
2) Модель построения бизнеса\сервисов\инфраструктуры\бизнес моделй на основе ITIL - довольно таки интересная, но требует колосальных денег\трудо затрат, впрочем один из основателей (ну или же вернее сказать ведущих специалистов) ITIL давно призанл, что ITIL, хороша, но не является лучшей моделью, а лишь сборником готовых опробированных решений.
3) Прецеденты работы да, офисов понятия не имею.
Хочу так же отметить, что давно-давно, когда я делал свой бизнес, именна эта модель и была избранна NN людей по разным областям были объединены и работали, первый наш офис был, организован на базе юр. конторы, с которой был заключен договор о сотрудничестве(консультация и пр.), на основании чего мы и находились в офисе. Так же у нас были люди, которые не занимались "нашим" бизнесом 100% а выполняли подряды по желанию, при этом занимаясь своим фрилансом со своим графиком. Естественно наша цель была формирование ооо и последующее развитие бизнеса, но в любом случае у нас были "пассажиры", которые работали сами на себя и иногда получали подряды, чему-то учились мы у них, чему-то они у нас.
В москве довольно много фирм, у которых в свободных помещениях сидят фрилансеры, и работают каждый над своим проектом, частично уделяя время на работу над подрядом комании\человека, который предоставляет им помещение, списывая часть оплаты, за услуги. С юридической точки зрения, их оформляют в штат или же по контракту\договору, как консультантов или же работников по определенному вопросу, что в полной мере является правдой, и юридически легализует их присуствие в помещении, для правоохранительных органов. И такой вид "сожительства", вполне жизнеспособен.
Если вы хотите собраться вместе и делать общее дело, это уход в сторону бизнес образования.
Если вы хотите,собраться вместе и каждый занматься своим делом, это как раз coworking.
Не правращайте "новое", в давно изъеденое "старое", за неимением опыта.
С юридической точки зрения, есть "множество" решений этой формы совместного "проживания", это все можно уточнить у юристов, прежде четко поставив задачи и разграничив зоны ответственности.
С точки зрени украть\нагадить, с каждым соучастнеком подписывается договор.
В общем-то вя организацию делается по принципу обычного ООО, за исключением формы юридического лица.
Естественно у большинства фрилансеров, нету таковых навыков для организации, я думаю тут напомощь могут прийти знакомые, с опытом в организации подобных мероприятий.
Во-первых, существуют разные модели построения библиотек по одной из версий их 9 и в зависимости от модели, разная степень избыточных методов при инициализации.
Во-вторых, benchmark всему голова :D
Пример сценария:
Ты подключаешь "большой" файл, который тащит за собой небольшое кол-во файлов на "все" случаи жизни.
Ты подключаешь "маленький" файл, который представляет из себя "lego", в результате чего, при наращивании функционала, открывается все большее кол-во файлов и плодятся наследуемости\инкапсуляции и прочие шалости ооп.
Класс, обрабатывается целиком перед выполнением, как на ошибки, так на инициализацию расходуется системное время\память.
Имхо всякие propel doctrine adodb - это некий концептуальный ивзрат из серии: "Фигасе я придумал".
В принципе "+", что изобретаете велосипед, а иначе он никогда не полетит :)
Концепт он как воздух - его можно гонять веками, без сырцов - это не более чем пиар.
А так же в самом коде.
>>Дилемма стартапа
К сожалению это не дилемма, а нетчо большее. Тут есть несколько подводных камней:
1) идея
У вас появилась идея, которую вы развиваете, пытаясь сделать более "рентабельно" ( как для монетизации, так и для скажем "популяризации" вашего проекта ), в данном случае иногда наступает эффект второй системы, т.е. пока вы проектируете все в первый раз, у вас растет ком идей, которые хотелось бы реализовать и уже почти реализованы, и в итоге весь проект стал идейной помойкой.
2) время
Конкуренты не дремлют, да и у вас ограниченное время, невозможно "безразмерно" тратить свое и чужое время в никуда.
3) бюджет
В любом случае есть бюджет, даже если собралась команда энтузиастов, в конце концов, они захотя есть, пить, курить и отдохнуть, а деньги то откуда-то надо брать, и вот этот вот заработок будет отнимать время.
>>Считается (не знаю кем), что оптимальное число команды-создателей должно быть не больше 3.
Данная форма "совладельцев" наиболее оптимальна и устойчива, т.к. не дает части совладельцев устроить "мятеж", а все потому, что долевой перевес 1 голоса решает( это если в кратце ) + есть некоторые юридические заморочки, которые делают эту схему наиболее устойчивой при равном распределении голосов.
Из личного опыта скажу 50\50 бизнес очень нервное занятие и "непонимание" всего лишь одного партнера(50%) - наглухо задушит весь бизнесс.
Опять же есть разные виды долей, я помню только 2 типа:
1) это голос
2) это % с прибыли
И то и то можно урегулировать "уставом" компании, что крайне редко делается в стартапах и в малом бизнесе тоже.
Хочется добавить всего одну вещь, у любого проекта должен быть "Журнал", в котором должно быть описано все( в вольной форме ), почему сделали так а не так, почему решили идти по этому пути или выбрали эту структуру( архетектуру ) - поверьте, вы в конце концов забудите( в действительносте забудите, почему ведущий программист сказал, что надо делать так ), а почему же было так, и снова или же сталкнетесь с этой "граблей" или "профукаете" момент, когда кто-то эти грабли починит.
В общем докуметация + журнал проекта - это важно :)
p.s. Не судите строго, это моё ИМХО и мой личный опыт.