Алексей Сундуков

Автор только вы, если заказчик вам не диктовал строки кода и т.п. (вот диктовал бы — вы бы оказывали техническое содействие по их вводу). Но исключительные права по умолчанию принадлежат заказчику, хотя вы вправе использовать эту программу для собственных нужд.

В коде и ресурсах не должно быть строк © yujin1st, хотя могут быть Author yujin1st, и не должно быть строк Author <Заказчик>, хотя могут быть © <Заказчик>

В данном случае вы не являетесь автором идеи, но являетесь автором реализации. Код же писали вы, значит автором являетесь вы.

Техническое — это, например, он дал Вам комп, на котором Вы писали. А то, что Вы писали — автором этого Вы и являетесь.

Вы скорее соавтором получаетесь.
А так — у заказчика авторство идеи и исключительные права.
У Вас авторство реализации. Вы можете где хотите говорить, что писали, делали, рисовали этот продукт, то есть он будет у Вас в портфолио, но никаких отчислений дополнительных, кроме как платы за выполненную работу Вы не получите.

Автором является исполнитель, права принадлежат заказчику в объеме предусмотренным договором. Авторство передать нельзя (в РФ).

радиатор побольше, вентилятор побольше, обороты поменьше.

Сам по себе ORM — банальная ничем не примечательная хрень. Это уже много раз делали в других фреймворках (например, RoR, Java) и описано в книгах про паттерны. Берешь, делаешь как в Руби и пользуешься хоть до посинения.

Пример с User::create() неудачный: у реальных объектов бывает по 20 свойств и фукнция с 20 аргументами будет выглядеть дико. Функции с подчеркиванием в начале — уродливые. Передавать __CLASS__ и подобные магические методы тоже не очень как-то.

Один из сложных моментов в проектировании ORM — оптимальная организация взаимодействия с хранилищем. Например, этот ваш пример:

> foreach(UsersGroup::getPremiumMembers()->orderBy('registration_date')->limit(10) as $user){
> echo $user->getCountry()->getCurrency()->getCode()."
";

Сколько запросов сгенерирует при использовании SQL-хранилища? По идее, должно быть в районе 3-4, причем данные справочников еще бы и стоило кешировать (ибо валюты у стран меняются очень редко) и обойтись 1-2 запросами. Если у вас в цикле для каждого юзера делается запрос — хлам это, а не ORM.

Второй момент — оверхед. Вы когда-нибудь считали, какая разница по времени выполнения запроса через ваш ORM и через mysqli_query() (включая время на загрузку и инициализацию классов ORM)? Посчитайте, наверняка у вас после этого вообще пропадет желание использовать ORMы.

Третий момент — масштабирование. Можно ли, к примеру, сделав огромный сайт на вашем ORM, не переписывая кода, реализовать расшардивание базы на 100 серверов (чтобы справиться с нагрузкой). Можно ли на нем делать проекты уровня хотя бы игр для соцсетей или вконтакта?

Если у вас есть решение хотя бы некоторых из описанных 3 проблем проектирования ORM, ваша статья на тему архитектурных решений и программистских хитростей была бы крайне интересна. Если нет решения — то такой орм любой школьник может сделать, как я уже сказал, прочтя мануал к рубионрейлс.

$query = '
   SELECT
       code
   FROM
        table
   WHERE
        id = ?';

использует второй вариант и начинайте с новой строки (Будет почти тоже самое что и 1-ый вариант).

+ используйте одинарные кавычки
+ используйте плейсхолдеры

Принимайте

Хм. Лично мое мнение, что хабравчанам интересно абсолютно все, что касается IT мира.
Практически на любую тему найдется своя аудитория.
Как по мне:
1. как вы защищаете канал(ы), данные.
2. как и как часто делаете бекапы, сколько времени уйдет на восстановление.
3. софт. что используете, свое/не свое, как устроено.
4. присоединюсь к sectus.

Прямо посекундная тарификация?
Если не секрет, то расскажите, пожалуйста, что за сервис.
Аналог из отрасли где это все стандартизировано и отработано.
В связи существует 2 метода оплаты: postpaid и prepaid. Postpaid — это грубо говоря счет, который может уходить в минус, в данном случае мимо.
Prepaid. Это тот способ который берет деньги до начала услуги, поэтому при приблежении к 0 отключает сервис. К примеру в ряде стран законодательно запрещено уводить препейдного абонента в минус, но это лирика.
Так вот, prepaid бывает двух типов (основных, на самом деле есть еще)
IEC — Immediate Event Charging и ECUR — Event Charging with Unit Reservation.
В первом случае, при возникновении события, происходит запрос к счету, счет проверяется и от него отпиливаетя стоимость услуги, после чего возвращается положительный ответ и событие продолжается. Проблема, завязка на единицу тарификации, если выбрать маленькую (секунду) — то очень ресурсоемко получается, а если квоту увеличить (до минуты) — то при отказе от услуги на 35й секунде средства за 25 секунд пропадут. Знакомая ситуация наверное…
Второй метод интереснее.
Выбирается 2 параметра. Размер квоты и единица тарификации, допустим 1 минута и 5 секунд. Событие инициируется, происходит запрос к счету, на счете блокируется сумма, и возвращаеся ответ, который содержит объем доступный для услуги (в примере время, а могут быть байты, клики, слоны...) И услуга начинает предоставляться. Как только заканчиваются ресурсы, к счету опять происходит обращение, в котором говорится о том, что ресурсы израсходованы, и хочу еще (ну или не хочу), в этом случае со счета списывается разервированная сумма, и резервитуется следующая квота. Если услуга прекращается до исчерпания квоты, то время округляется ввепх до единицы тарификации (с 32 секунл до 35) и списываются деньги только за 35 секунд, за 25 возвращаются.
Это как организуется работа со счетом.
Совсем подробно можно почитать вот тут www.3gpp.org/ftp/Specs/archive/32_series/32.299/32299-700.zip Пункт 6.3.2, пугаться не надо, картинки понятные.

Ух расписался. Это половина, вторая часть — то как контролировать каждое событие. А тут без примера не могу ничего сказать.

FireBug, не подойдет?
getfirebug.com

почему люди не могут ничего написать не спросив кого-то?

1. Забудьте про инструменты. Вам насоветую всякого, вы пойдете применять, но будете как мартышка и очки, не знать куда их еще прицепить, чтобы заработать денег. Инструмент эффективен только тогда, когда держущая его рука знает, как его применить наилучшим способом. Пока не наберетесь опыта, экспериментировать с инструментами я бы не советовал, только зря потратите время. Лучше сфокусируйтесь на других вещах.
2. Ничто не мотивирует работника лучше, чем бесконечные деньги и бесконечные знания. Рано об этом думать начали.
3. Серьезные заказчики очень сильно редко заказывают проекты у начинающих вебстудий. Потому что им нужно решать свои бизнес-задачи, делать это быстро и эффективно. Нужно набраться опыта, наростить жирок в виде портфолио, и тогда вы резко перейдете в лигу повыше.

Что нужно?
1. Составить некое подобие бизнес-плана. Нужно описать всю затратную и прибыльную часть. Любой проект должен приносить вам прибыль, иначе вы попадете в ситуацию, когда для оплаты труда работников вам потребуется потратить деньги будущих проектов. Т.е. вы будете жить в долг. Из этой ситуации очень сложно выпутаться.
2. Никогда не тратьте больше, чем требует бизнес-план. Лучше пусть у вас на счету будут оставаться деньги, они пригодятся стабилизировать неровности поступления средств. Этот период становления на рынке занимает в среднем года за 3. Вы или выживете, или прогорите. Научитесь не опускаться ниже линии убыточности.
3. Никогда не демпингуйте сверх меры.
4. Качество всегда и во всем. Вы должны сделать клиенту качественный продукт. Просто обязаны. Себе, не заказчику.
5. Всегда держите свое слово. С балаболами на рынке никому не интересно работать
6. Цените свой труд. Вы продаете или свои знания или свои руки и мозги. В первом случае заказчик доверяет вам выполнить работу, потому что вы лучше него знаете, что ему нужно. Во втором вам платят за то, что вы молча выполняете прихоти платящих деньги. Первых трудно найти, вторых — пруд пруди. Первые зарабатывают, вторые — выживают.

Удачи вам с бизнесом.

До того как привлекать серьезных заказчиков, вы должны показать себя с серьезной стороны. Я не имею ввиду деловые встречи и заумные речи, я про квалификацию ваших специалистов, в первую очередь, конечно-же, про портфолио. Если портфолио нет, то крайне настоятельно советую потренироваться на мелких заказах. Не сколько для портфолио, сколько для обкатки всего вашего коллектива и механизмов взаиомдействия. А дальше уже можно стряпать портфолио.

Насчет организации работы.
Это уже очень субъективный вопрос, который зависит от многих факторов, в большинстве своем выбор инструментов каждый работник сделает по своему усмотрению. А если вы насчет взаимодействия, то для управления заданиями мы используем простенький teamer.ru. В нем нет ничего лишнего, и нам этого вполне хватает. А главное, на практике выявлено, что интерфейс на русском языке чуточку легче воспринимается, и задания кажутся легче :)
А уж про всякие там git, svn, валидаторы, веб-серверы и оптимизаторы это вам должны ваши работники рассказать. Ведь вы нанимаете людей, способных научить вас, а не вы их :)

Насчет взаимодействия “начальник-подчиненный”. Сколько бы нам не показывали крутых европейских примеров совершенно горизонтальной структуры компании (совершенно радикальна в этом плане Valve), некая организация все же не повредит. А если вы являетесь работодателем, то есть работники работают за зарплату, а не за доли в проектах, то тогда не стоит забывать о быстрой ротации кадров в условиях российских реалий, что играет почти ключевую роль в срыве сроков заданий.
Но, главное, по моему мнению — это полная свобода работников во всех отношениях. Как в выобре рабочего времени, так и в выборе заданий, которые они будут реализовывать. Помните — ключевой мотивацией является не кнут и пряник, а желание самого работника.

C 3-4
Проблем много:
O/Q
J=L
I=J

и тд

Поддержку postfix

cookies не костыль, собственно для этого они и придуманы (сессия — дальнейшее развитие идеи)

А у вас противоречие в условиях, по-моему:
Вариант с GET не подходит, ибо данные явно висят в url противоречит но через обычную ссылку их не передашь. Либо данные висят в урл, либо через обычную ссылку (без дополнительных скриптов на клиентской стороне) их не передать. Третьего не дано.

Может устроит вариант:
1. На исходной странице обычная GET ссылка на промежуточную страницу с данными в URL, нажимаем
2. Сервер принимает данные, пишет их в сессию и делает редирект на целевую страницу без данных в URL
3. Целевая страница достаёт данные из сессии и тут же сессию очищает.

Если пользователь не смотрит куда ведёт ссылка (или его браузер не показывает), то данные в URL мелькнут в адресной строке очень не надолго на современном ненагруженном компе и быстром инете.

Опять же если стоит задача скрыть от пользователя данные полностью, то это не реально, мониторить трафик умеют сейчас все популярные браузеры. Можно усложнить жизнь шифруя данные, но только усложнить. А для защиты от случайной утечке данных по сценарию типа «ломщик увидел секретный url, запомнил и дома его ввёл» моего сценария, имхо, достаточно.

Вопрос поставлен не совсем корректно, т.к. может быть 2 трактовки:

1. Если речь идет о веб-скриптах, которые выполняются последовательно, то чем вам не нравится сессия? В данном случае это не костыль — она именно для этого и придумана. Если не нравится непосредственно стандартная реализация, то можно взять собственную (принципиально аналогичную): генерировать ID клиента (сессии) и передавать его через get/post/cookie (по вкусу), а уже сами данные хранить либо в файлах, либо в базе данных, и получать с помощью этого идентификатора в качестве ассоциативного ключа.

Непосредственно данные через куки, гет и пост передавать естественно в данном случае не стоит: эти вещи всегда можно подделать, т.к. они идут через клиента. Это можно назвать костылем :)

================
2. Если же речь идет о выполняющихся одновременно 2 шелл-скриптах, т.е. межпроцессное взаимодействие (IPC), то тут можно использовать разные более или менее системно-зависимых вариантов. От стандартных механизмов IPC: семафоры, сообщения, шаред блок памяти, до специфичных вещей вроде именованного пайпа или сокета; или же аналогичных п.1 вещей (база данных/файлы).