Мне одному кажется, что подобного вида решение хорошо подходит для слабоструктурированной информации, где нужно отслеживать связи данного конкретного объекта с чем-то, но при этом получение списка объектов, обладающих определенными свойствами, определенными связями или определенными связями с другими объектами с определенными свойствами (и т.д.) будет вызывать серьезные трудности?
Или еще кому-то приходила такая мысль? :)
Вообще, похоже на построение структуры БД типа "нейронная сеть".
Не так. Просто для меня формулировка "до ближайшего порта" - совершеннейшая дикость!
Сначала "кто везет", потом "как везет". Все остальное - после. И отправка денег - в том числе :)
Да, забыл сразу.
"Транспортировка до ближайшего порта - это то же самое, что транспортировка до ближайшего аэропорта, только по морю". А что, есть такая? Ну, кроме как "передать через летчиков"? :)
Есть компания, которая осуществляет перевозку. У нее есть сеть пунктов, в которых она присутствует. Поэтому сразу известно, из какого и в какой порт (аэро или нет) можно этой компанией отправить. И какой конкретно компанией.
1) Это еще не повод дружно начать постить сюда топики на тему "как славненько мы вчера нажрались" :) Утрирую, конечно, но общий смысл, надеюсь, понятен?
2) Да. И это - хорошо. Потому что "Очинь понравилась, пеши исчо" - оно, конечно, читать приятно... но сподвигнуть на что-то конструктивное в жизни способна только здоровая критика.
3) Даже не найдя ничего для себя нового в Вашем тексте, и имея кое-что добавить, я ни в коей мере не считаю для себя возможным с таким уровнем чему-то кого-то учить. Вы себя - считаете :)
4) Я не говорил про дело целиком, я говорил про ту зону, в которую попали лично Вы. И на основе того, что Вы написали.
Возможно, у Вас что-то изменилось и накладные не такие высокие.
А возможно, рентабельность у Вас сейчас такая, что покрывает эти накладные. Но тут есть серьезный риск того, что (даже тупо посмотрев на Вас) кто-то станет заниматься тем же самым. Но, например, сразу возьмет кредит и будет возить более крупные партии. И Вы конкуренции с ним не сможете выдержать.
Да тон, в общем-то, из-за того, что вся статья оказалась больше похожа на "а чо вчера былаааа!..", хотя Вы, судя по всему, собирались многому научить людей. Прежде чем учить других (особенно многому) неплохо было бы хорошо научиться самому.
В противном случае получается профанация и пупулизм, которого сейчас на каждом углу. А вот дельных и профессиональных статей - днем с огнем.
А вообще - да. Есть некий порог перехода, связанный с "ценой выхода на рынок". То есть, переход от привоза и продажи с разведанных мест (eBay, Yahoo) проверенными каналами (USPS, посредники), которую осуществляет частное лицо, ловко мышась от родного государства, до средне-мелкооптовых закупок с нормальной растаможкой, услугами таможенных брокеров, а то и специальных компаний, которые сами везут и сами же таможат. В первом случае накладные маленькие, во втором - скидки за опт (причем не только от продавца, но и "удельный вес" услуг по растаможки на единицу товара и т.д.)
Вы же ловко попали строго между, получив все минусы от обоих и ни одного плюса.
Чаще всего нахождение в этой зоне "посредине" экономически не выгодно. Если есть желание заниматься - надо искать другие возможности и каналы.
Но не писать про это статьи! У нас каждый челнок с рынка может выдать более ценную информацию.
Н-да... Деццкий сад - штаны на лямках.
Моя учительница по математике говорила замечательную фразу: "Думать надо даже на физкультуре! А то не в ту сторону побежишь".
У автора диаметрально противоположная стратегия: "К черту все! Берись и делай!"
Все описанное далее - не более, чем ее результат.
Потому как даже беглый поиск по инету выдаст вам http://www.ebay-forum.ru/phpBB2/
Сидите и изучайте, прежде чем отправлять индусам по 500 баксов за "доставку до ближайшего порта" (это что за транспортировка-то такая? бутылки в океан, разве что...)
Исходя из собственного опыта (коей немного больше, чем у автора) позволю себе немного подкорректировать выводы.
1) Самый удобный способ отправки - USPS (если доступен). Экспресс-посылки этой службы передаются на территории России EMS'у. Обычные - нашей родной Почте России. Если посылка не задержана, в первом случае ее привезут вам домой, во втором - сами в свое почтовое отделение пойдете.
Из-за бардака иногда второй способ получается быстрее :)
Стоит отметить (и на разных форумах это указано), что беспошлинно можно ввозить товаров для личного употребления на сумму до 10,000р на одно лицо раз в неделю. Причем, это если отправка идет через то ли уполномоченных, то ли зарегистрированных почтовых компаниях. К коим у нас и относятся только EMS и Почта России. Все прочие UPS, FedEx, DHL - это транспортные компании и при использовании их планка "падает" до 5000р в неделю на человека.
2) При посещение грузового терминала, не смотря на доброжелательность таможенников, все же придется там постоять, а еще до туда надо добраться - а это аэропорт обычно.
3) Мелкие грузы и UPS привозит домой. DHLем не пользовался никогда.
4) Иногда выгоднее разбить посылку на две - все равно получится выгоднее. Меньше вероятность задержания таможней, т.к. меньше похоже на партию для коммерческого использования. Задержание же, кроме времени, грозит еще и пошлиной в 30% от суммы выше 10,000р (5,000р в случае UPS, DHL и т.д.)
5) Зачастую выгодно пользоваться посредниками "там". Не смотря на дополнительные проценты, чаще получается дешевле из-за возможности доставить каким-нибудь хитрым способом (некоторые имеют канал через Украину, груз приходит сюда уже растаможенным). Кроме прочего, получателя на своей территории продавцы "кидать" боятся.
6) Western Union не просто рисковый, но еще и достаточно дорогой способ. Лучший, конечно, Paypal - дешево (для покупателя - даром! :) и всегда стоит на стороне покупателя.
Простите, но "co-working" - это "совместная РАБОТА". Потому советую при общении с официальными лицами его не употреблять: далеко не все из них не знают английского. Но почти все будут готовы поинтересоваться, на кого вы работаете, как получаете деньги (а должны получать, раз работаете да еще и офис снимаете), платите ли налоги, какие, сколько.
Конкретно за некоммерческие организации сейчас взялись, потому что слишком много из них было "ширмой" для какой-то деятельности, финансируемой из-за рубежа. И, зачастую, не самой полезной для нашей страны (ну, как минимум, по мнению чиновников). Потому по ним что-то ужесточили недавно и стали контролировать. А вы как раз попадаете - и некоммерческие, и финансирование из-за рубежа :)
Я бы посоветовал сделать тупое ООО, заняться "консалтингом". Я так понимаю, вы и так будете им заниматься, типа того :)
Сесть на упрощенку и сильно не париться. В противном случае могут задолбать.
Вспомнил детали.
На RoR я пользовался плагином, организующим дерево в БД. Там right и left прописывались для каждой записи (обновлялись при вставке, удалении, переносе нода в другое место). В результате, если выбирать записи в порядке возрастания right и по дате создания (можно по id), то они выдавались точно в том порядке, в котором должны были бы отразиться на экране. Дополнительно я высчитывал только level, но это не сложно, имея для каждой записи parent_id.
По вызовам представдений. Два из них были примитивными - открытие дива, еще что-то. Максимум - вставка id для дива, чтобы было как хайдить. Второй - одни закрытия дивов. Так что можно кэшировать хоть чем :)
А можно вопрос?
Как у вас обстоят дела с "компетентными органами"? Ну, которые придут спрашивать, что за организация тут сидит, чем занимается, откуда деньги?
А если всего этого "нет", то не производят ли контрофактной продукции на самом деле, чтобы наживаться на Microsoft и прочих?
Я точно не помню, но мне кажется, что не было. Вот как сделал - сейчас затруднюсь сказать, подумал - не помню. Но при использовании рекурсии получается дерево, планарный массив получается криво.
На вызовы я не заморачивался, RoR хорошо все кэширует.
В моем случае идеей было - вывод комментариев из БД в древовидном представлении с возможностью "скрыть-показать" поддерево. У вас какая-то другая задача?
С точки зрения PHP - это обычный массив.
В Руби они делятся: массив это то, что с индексами "1, 2, 3...", причем если был инициализирован 1й и 5й, то появятся 2, 3, 4 равные nil, хэш - это то, что в PHP называют "массивы" - какие попало индексы.
Планарный в плане "1 -> первый камент", "2 -> второй камент", даже если второй - это ответ на первый.
А не в первом содержится "comments -> array(...)".
И что, что дерево?
Я на RoR реализовал одним циклом по планарному хэшу. Там, правда, участвовал level, а хэш был отсортирован правильно (не помню сейчас, как я это сделал).
Но в результате все получалось правильно вставленными дивами, которые можно было хайдить, чтобы свернуть цепочку подответов.
Простите, но это тоже самое, что "надо жить честно!". Надо, кто ж спорит! Вы, вот, честно живете? Например - да. А вокруг вас? То-то и оно. Вы ж не по собственному мнению, а по мнению некоторых других фильтроваться собрались. И вы хотите опираться на их мнение?
А я на хабре уже устал встречать заминусованные каменты, которые написаны нейтрально, кратко и по делу, а на них стоит пара-тройка минусов. Значит - только за мнение, которое не совпадает с мнением минусующих.
Про статьи не скажу, а комментарии тут минусуют не за смысл, не за корректность и не за отсутствие информации. А за то, что твое мнение кому-то не нравится.
Хотите читать только "единственно правильное" мнение? :)
Автор, вы уж простите меня, я буду выступать резковато. Но я для этого даже зарегистрировался специально.
Скажите, вы нас за даунов держите? Сначала первая часть с, мягко говоря, сомнительными примерами с для ООП и не для ООП. И то каждый из трех строк. При том, что кодогенерация не имеет к ООП вообще никакого отношения.
Давайте определимся, чтобы не было путаницы, когда каждый о своем - что такое кодогенерация. А то вы своими примерами на генерацию HTML тоже всех путаете.
Кодогенерация - это _автоматическое_ создание одним исполняемым кодом другого _исполняемого_кода_.
Шаблонизаторы, составляющие HTML - это не кодогенерация, в общем случае. Потому что это - создание документа. Можно, конечно, придираться по мелочам, мол HTML - это язык, он выполняется браузером и т.д., но на самом деле если и язык в этом понимании, то недоязык. Нет там ни управляющих конструкций, ни данных, ничего там нет. Хотя тот же Smarty имеет некую кодогенерацию.
А вот компиляторы - это как раз самые что ни на есть кодогенераторы. Это как раз программы, создающие из входных данных (в данном случае - "текстов программ на языке высокого уровня") другой _исполняемый_ код.
Код не обязан быть непосредственно в машинных кодах, естественно. Те же скаффолды создают код на том же языке, что и написаны. А оптимизатор PHP преобразует код в некое внутреннее представление для ускоренного выполнения. Но в любом случае, это - осмысленный полноценный код, способный передать логику и оперировать данными, на некой существующей системе выполнения данного кода.
(Я сразу извиняюсь за некий сумбур в терминологии и определениях, но, я думаю, сама мысль, которую я высказываю, достаточно понятна. Потому не надо придираться к словам вместо смысла. Комментарии приму с благодарностью)
Предлагаю разделить все данные, которые имеются для получения результата, на два больших класса:
1) Логика. Назовем ее так. Для обычного компилятора это - код программы. Однако это могут быть и какие-то другие системы описания.
2) Данные. Конкретно то, что обрабатывается Логикой.
В результате, мы имеем ДВА(!) подхода:
1) Интерпретация. Есть некие входные данные (вся совокупность - Логика и Данные), есть написанный нами код, который на основании этих данных выполняет определенные действия и что-то делает с результатом.
2) Компиляция. Есть некий компилятор, на вход которому подается Логика и он _генерит_исполняемый_код_, и уже подав его на вход некой системы вместе с Данными мы получаем результат.
В чем разница этих двух подходов, в чем их плюсы и минусы.
1) Очевидно, что выполнение после компиляции _быстрее_ (мы пропускаем каждый раз при выполнении один шаг - разбор Логики на входе). Это плюс компиляции.
2) Очевидно, что разработка компилятора - дополнительные затраты, причем зачастую достаточно существенные. Это минус компиляции.
3) Очевидно, что компилятор должен быть сложной и сильно связанной системой, поэтому внесение изменений в него (добавление возможностей для описания Логики) намного сложнее и затратнее, чем добавление возможности обработки этих же возможностей интерпретатором. Это тоже минус компиляции.
Отсюда напрашивается достаточно простой вывод - разработка компилятора обоснована либо в критичной по производительности системе, либо при его (компилятора) _многократном_ применении, когда описание Логики _существенно_ меньше получаемого в результате компиляции объема кода.
Вот в таком русле предлагаю и вести дискуссию и последующих статьях. Плюсы и минусы этих двух подходов (а они есть, разные и много), в каком случае стоит использовать одно, в каком - нет.
Потому что доказывать нам, что скаффолды, сгенерированные автоматически - это круто и полный хайтек, не надо. Я сомневаюсь, что кто-то оставляет их без переработки, почти равной по затратам написанию всего этого с нуля.
Или еще кому-то приходила такая мысль? :)
Вообще, похоже на построение структуры БД типа "нейронная сеть".
Сначала "кто везет", потом "как везет". Все остальное - после. И отправка денег - в том числе :)
"Транспортировка до ближайшего порта - это то же самое, что транспортировка до ближайшего аэропорта, только по морю". А что, есть такая? Ну, кроме как "передать через летчиков"? :)
Есть компания, которая осуществляет перевозку. У нее есть сеть пунктов, в которых она присутствует. Поэтому сразу известно, из какого и в какой порт (аэро или нет) можно этой компанией отправить. И какой конкретно компанией.
2) Да. И это - хорошо. Потому что "Очинь понравилась, пеши исчо" - оно, конечно, читать приятно... но сподвигнуть на что-то конструктивное в жизни способна только здоровая критика.
3) Даже не найдя ничего для себя нового в Вашем тексте, и имея кое-что добавить, я ни в коей мере не считаю для себя возможным с таким уровнем чему-то кого-то учить. Вы себя - считаете :)
4) Я не говорил про дело целиком, я говорил про ту зону, в которую попали лично Вы. И на основе того, что Вы написали.
Возможно, у Вас что-то изменилось и накладные не такие высокие.
А возможно, рентабельность у Вас сейчас такая, что покрывает эти накладные. Но тут есть серьезный риск того, что (даже тупо посмотрев на Вас) кто-то станет заниматься тем же самым. Но, например, сразу возьмет кредит и будет возить более крупные партии. И Вы конкуренции с ним не сможете выдержать.
PS. Вы не правы, если думаете, что я злобничаю :)
В противном случае получается профанация и пупулизм, которого сейчас на каждом углу. А вот дельных и профессиональных статей - днем с огнем.
А вообще - да. Есть некий порог перехода, связанный с "ценой выхода на рынок". То есть, переход от привоза и продажи с разведанных мест (eBay, Yahoo) проверенными каналами (USPS, посредники), которую осуществляет частное лицо, ловко мышась от родного государства, до средне-мелкооптовых закупок с нормальной растаможкой, услугами таможенных брокеров, а то и специальных компаний, которые сами везут и сами же таможат. В первом случае накладные маленькие, во втором - скидки за опт (причем не только от продавца, но и "удельный вес" услуг по растаможки на единицу товара и т.д.)
Вы же ловко попали строго между, получив все минусы от обоих и ни одного плюса.
Чаще всего нахождение в этой зоне "посредине" экономически не выгодно. Если есть желание заниматься - надо искать другие возможности и каналы.
Но не писать про это статьи! У нас каждый челнок с рынка может выдать более ценную информацию.
Моя учительница по математике говорила замечательную фразу: "Думать надо даже на физкультуре! А то не в ту сторону побежишь".
У автора диаметрально противоположная стратегия: "К черту все! Берись и делай!"
Все описанное далее - не более, чем ее результат.
Потому как даже беглый поиск по инету выдаст вам http://www.ebay-forum.ru/phpBB2/
Сидите и изучайте, прежде чем отправлять индусам по 500 баксов за "доставку до ближайшего порта" (это что за транспортировка-то такая? бутылки в океан, разве что...)
Исходя из собственного опыта (коей немного больше, чем у автора) позволю себе немного подкорректировать выводы.
1) Самый удобный способ отправки - USPS (если доступен). Экспресс-посылки этой службы передаются на территории России EMS'у. Обычные - нашей родной Почте России. Если посылка не задержана, в первом случае ее привезут вам домой, во втором - сами в свое почтовое отделение пойдете.
Из-за бардака иногда второй способ получается быстрее :)
Стоит отметить (и на разных форумах это указано), что беспошлинно можно ввозить товаров для личного употребления на сумму до 10,000р на одно лицо раз в неделю. Причем, это если отправка идет через то ли уполномоченных, то ли зарегистрированных почтовых компаниях. К коим у нас и относятся только EMS и Почта России. Все прочие UPS, FedEx, DHL - это транспортные компании и при использовании их планка "падает" до 5000р в неделю на человека.
2) При посещение грузового терминала, не смотря на доброжелательность таможенников, все же придется там постоять, а еще до туда надо добраться - а это аэропорт обычно.
3) Мелкие грузы и UPS привозит домой. DHLем не пользовался никогда.
4) Иногда выгоднее разбить посылку на две - все равно получится выгоднее. Меньше вероятность задержания таможней, т.к. меньше похоже на партию для коммерческого использования. Задержание же, кроме времени, грозит еще и пошлиной в 30% от суммы выше 10,000р (5,000р в случае UPS, DHL и т.д.)
5) Зачастую выгодно пользоваться посредниками "там". Не смотря на дополнительные проценты, чаще получается дешевле из-за возможности доставить каким-нибудь хитрым способом (некоторые имеют канал через Украину, груз приходит сюда уже растаможенным). Кроме прочего, получателя на своей территории продавцы "кидать" боятся.
6) Western Union не просто рисковый, но еще и достаточно дорогой способ. Лучший, конечно, Paypal - дешево (для покупателя - даром! :) и всегда стоит на стороне покупателя.
Это если вкратце.
Конкретно за некоммерческие организации сейчас взялись, потому что слишком много из них было "ширмой" для какой-то деятельности, финансируемой из-за рубежа. И, зачастую, не самой полезной для нашей страны (ну, как минимум, по мнению чиновников). Потому по ним что-то ужесточили недавно и стали контролировать. А вы как раз попадаете - и некоммерческие, и финансирование из-за рубежа :)
Я бы посоветовал сделать тупое ООО, заняться "консалтингом". Я так понимаю, вы и так будете им заниматься, типа того :)
Сесть на упрощенку и сильно не париться. В противном случае могут задолбать.
На RoR я пользовался плагином, организующим дерево в БД. Там right и left прописывались для каждой записи (обновлялись при вставке, удалении, переносе нода в другое место). В результате, если выбирать записи в порядке возрастания right и по дате создания (можно по id), то они выдавались точно в том порядке, в котором должны были бы отразиться на экране. Дополнительно я высчитывал только level, но это не сложно, имея для каждой записи parent_id.
По вызовам представдений. Два из них были примитивными - открытие дива, еще что-то. Максимум - вставка id для дива, чтобы было как хайдить. Второй - одни закрытия дивов. Так что можно кэшировать хоть чем :)
Как у вас обстоят дела с "компетентными органами"? Ну, которые придут спрашивать, что за организация тут сидит, чем занимается, откуда деньги?
А если всего этого "нет", то не производят ли контрофактной продукции на самом деле, чтобы наживаться на Microsoft и прочих?
Короче, как что это у вас юридически оформлено?
На вызовы я не заморачивался, RoR хорошо все кэширует.
В моем случае идеей было - вывод комментариев из БД в древовидном представлении с возможностью "скрыть-показать" поддерево. У вас какая-то другая задача?
Минусы рекурсии сами назовете? :)
В Руби они делятся: массив это то, что с индексами "1, 2, 3...", причем если был инициализирован 1й и 5й, то появятся 2, 3, 4 равные nil, хэш - это то, что в PHP называют "массивы" - какие попало индексы.
Планарный в плане "1 -> первый камент", "2 -> второй камент", даже если второй - это ответ на первый.
А не в первом содержится "comments -> array(...)".
Я делал вывод с планарного хэша. У меня были вьюшки:
- сам камент.
- начало блока камента(подкамента).
- конец блока камента(подкамента).
Цикл был по хэшу, в зависимости от разности level предыдущего и текущего выводились начала-концы блоков. И сам камент.
Алгоритм был немного завернутый, но красивый и правильный.
В конце концов, для этого мы и программисты, чтобы алгоритмы писать.
А то модно стало тесты на скорость вместо этого писать :)
Я на RoR реализовал одним циклом по планарному хэшу. Там, правда, участвовал level, а хэш был отсортирован правильно (не помню сейчас, как я это сделал).
Но в результате все получалось правильно вставленными дивами, которые можно было хайдить, чтобы свернуть цепочку подответов.
А я на хабре уже устал встречать заминусованные каменты, которые написаны нейтрально, кратко и по делу, а на них стоит пара-тройка минусов. Значит - только за мнение, которое не совпадает с мнением минусующих.
Хотите читать только "единственно правильное" мнение? :)
Скажите, вы нас за даунов держите? Сначала первая часть с, мягко говоря, сомнительными примерами с для ООП и не для ООП. И то каждый из трех строк. При том, что кодогенерация не имеет к ООП вообще никакого отношения.
Давайте определимся, чтобы не было путаницы, когда каждый о своем - что такое кодогенерация. А то вы своими примерами на генерацию HTML тоже всех путаете.
Кодогенерация - это _автоматическое_ создание одним исполняемым кодом другого _исполняемого_кода_.
Шаблонизаторы, составляющие HTML - это не кодогенерация, в общем случае. Потому что это - создание документа. Можно, конечно, придираться по мелочам, мол HTML - это язык, он выполняется браузером и т.д., но на самом деле если и язык в этом понимании, то недоязык. Нет там ни управляющих конструкций, ни данных, ничего там нет. Хотя тот же Smarty имеет некую кодогенерацию.
А вот компиляторы - это как раз самые что ни на есть кодогенераторы. Это как раз программы, создающие из входных данных (в данном случае - "текстов программ на языке высокого уровня") другой _исполняемый_ код.
Код не обязан быть непосредственно в машинных кодах, естественно. Те же скаффолды создают код на том же языке, что и написаны. А оптимизатор PHP преобразует код в некое внутреннее представление для ускоренного выполнения. Но в любом случае, это - осмысленный полноценный код, способный передать логику и оперировать данными, на некой существующей системе выполнения данного кода.
(Я сразу извиняюсь за некий сумбур в терминологии и определениях, но, я думаю, сама мысль, которую я высказываю, достаточно понятна. Потому не надо придираться к словам вместо смысла. Комментарии приму с благодарностью)
Предлагаю разделить все данные, которые имеются для получения результата, на два больших класса:
1) Логика. Назовем ее так. Для обычного компилятора это - код программы. Однако это могут быть и какие-то другие системы описания.
2) Данные. Конкретно то, что обрабатывается Логикой.
В результате, мы имеем ДВА(!) подхода:
1) Интерпретация. Есть некие входные данные (вся совокупность - Логика и Данные), есть написанный нами код, который на основании этих данных выполняет определенные действия и что-то делает с результатом.
2) Компиляция. Есть некий компилятор, на вход которому подается Логика и он _генерит_исполняемый_код_, и уже подав его на вход некой системы вместе с Данными мы получаем результат.
В чем разница этих двух подходов, в чем их плюсы и минусы.
1) Очевидно, что выполнение после компиляции _быстрее_ (мы пропускаем каждый раз при выполнении один шаг - разбор Логики на входе). Это плюс компиляции.
2) Очевидно, что разработка компилятора - дополнительные затраты, причем зачастую достаточно существенные. Это минус компиляции.
3) Очевидно, что компилятор должен быть сложной и сильно связанной системой, поэтому внесение изменений в него (добавление возможностей для описания Логики) намного сложнее и затратнее, чем добавление возможности обработки этих же возможностей интерпретатором. Это тоже минус компиляции.
Отсюда напрашивается достаточно простой вывод - разработка компилятора обоснована либо в критичной по производительности системе, либо при его (компилятора) _многократном_ применении, когда описание Логики _существенно_ меньше получаемого в результате компиляции объема кода.
Вот в таком русле предлагаю и вести дискуссию и последующих статьях. Плюсы и минусы этих двух подходов (а они есть, разные и много), в каком случае стоит использовать одно, в каком - нет.
Потому что доказывать нам, что скаффолды, сгенерированные автоматически - это круто и полный хайтек, не надо. Я сомневаюсь, что кто-то оставляет их без переработки, почти равной по затратам написанию всего этого с нуля.