и интернет магазин

и корпоративный портал для сотрудников

да, у битрекса, насколько я знаю, есть на все случаю жизни функции

да

ну, пилить это все не имеет смысла

не важно какой там код в корпоративном портале

оно работает, им пользуются 700 человек

главное, что проверенный код, а не костыли свои

Ну далеко на нем вряд ли уедешь

Битрикс только у нас популярен. Зарубежом его никто не использует и ничего запускаются. Есть другие варианты.

ну, основатели уехали

запускались шестером

Кароче бизнесная коробочка для компаний выстреливает, а как с маштабированием?

привлекли 40 млн баксов

теперь тут работает 700 человек

а масштабирование - микросервисы

привлекли 40 млн баксов

carprice?

да

Ну за 40 миллионов они бы и на условном Django все это сдделали бы за полгода, о котором ты говоришь

они привлекли спустя пол года работы

а не сразу

пальцем в небо - взяли бы лучше net cat

меньше негативных отзывов

ну, не совсем в небо

Саш, там люди опытнее и меня и тебя в роли предпринимателей

президент carprice владеет многими стартапами

он любит покупать - продавать

Раньше помню лет 8 назад когда лазили в код Битрикса, очень смеялись что там понаписано. гавнокод высшей степени, можно было в мемы постить. Но говорят с того времени переписали более менее профессионалы все это барахло)

Раньше помню лет 8 назад когда лазили в код Битрикса, очень смеялись что там понаписано. гавнокод высшей степени, можно было в мемы постить. Но говорят с того времени переписали более менее профессионалы все это барахло)

Честно, там не так уже все плохо

можно лучше и надо лучше

Ну говорят переписали

если человек понимает в бизнесе, это не значит, что он выбирает CMS правильно и его бизнес работает хорошо благодаря, а не вопреки этой CMS

но, для mvp там более чем хорошо все

да, они полностью переписали ядро

возможно, с другой CMS бизнес бы работал ещё лучше на начальных этапах

если человек понимает в бизнесе, это не значит, что он выбирает CMS правильно и его бизнес работает хорошо благодаря, а не вопреки этой CMS

в том числе хорошо понимает, что не стал писать на фреймворке

ну так и правильно

ну, Саш

ты в битриксе сто лет не ковырялся

там уже не такой говнокод

битрикс все ненавидят

ну, что я могу сказать, идиоты

битрикс выгоден партнёрам

битрикс эффективен для другого

его продавать выгодно

вот поэтому битрикс популярен

После того как их купил 1с, там все вменяемо сделали, а может и до того, но раньше там было действительно смех

Саш, твое построение мнения не всегда правильно

то что говорят на форумах, во первых может быть неактуальным

сейчас вообще CMS'ки не нужны)

есть сервисы

во вторых может быть от некомпетентого автора

SaaS'ы

это ещё проще и быстрее

и через IFTTT или Zapier их объединять

спорно очень спорно

пока не сделаешь, не узнаешь

издалека комментировать - неправильная позиция

издалека - всегда просто

"а чтож там... тяп-ляп и все"

не всегда так

i repeat, давай заниматься нашим проектом, читай наш чат....))

Не забуду как запускали сайт Олимпиады на Битриксе и он лежал каждый день, потому что сервак не справлялся

Это конечно решается, но все равно было весело читать новости

олимпиада немного другое

это статичный проект

ему выделен бюджет

ERROR: S client not available

его заранее делают

как таковой спешки как у стартапа нет

Не совсем другое. Им нужно было так же быстро запустить. Они так же выбрали систему. Нооно долго тупило

значит менеджеры как то неправильно все организовали

если я не ошибаюсь, о том, где пройдет следующая олимпиада сообщают за 4 года

это означает, у них есть 4 года на это все

и еще пару миллиардов...

могли и сами написать

Сайт заранее нужен, там же через него следят за строительством объектов. Там было пару месяцев на все провсе

у них там еще портал был для обычных людей

он же на сразу нужен

Сразу

i repeat, давай заниматься нашим проектом, читай наш чат....))

да, мы тут с тобой много холиварим) давай я тебя забаню, я тут модер) ?

спорно очень спорно

объединять готовое быстрее, чем писать своё, если это типовые вещи, в этом смысле коробка лучше фреймворка, а SaaS лучше коробки

лучше в значении "быстрее реализовать"

вот, кстати, плохо, что вокруг Django кроме CMS коробочных решений мало

сейчас есть https://wagtail.io/ и это здорово, нужно больше подобных проектов

Интересно, а есть какие-то причины, чтобы переопределять имя таблиц в СУБД, а не юзать app_model? Мне кажется, это усложняет понимание, т.к. имя модели и таблицы отличается, причем правил уже нет

Хочешь свое имя таблицы предопределяешь. Я часто задаю, мне так удобнее.

Интересно, а есть какие-то причины, чтобы переопределять имя таблиц в СУБД, а не юзать app_model? Мне кажется, это усложняет понимание, т.к. имя модели и таблицы отличается, причем правил уже нет

вообще, да, в этом есть смысл, особенно, если ты управляешь структурой таблиц извне

и можно запретить Django менять структуру

лично мне нравится http://www.datanamic.com/dezign/ [кстати, там триал, можно бесплатно пользоваться какое-то время]

можно следить за структурой таблиц отдельно от Django, то есть не пользоваться миграциями и тогда будет желание запретить Django что-то там менять и явно указывать, какая модель, с какой таблицей связана

то есть сначала делать структуру таблиц, а уже потом Django указывать на эту СУБД, в RoR, кажется, какой-то подобный подход (сначала структура таблиц, потом модели, а не наоборот)

тут много новичков, наверное, мне лучше подробнее объяснить: когда проект простой это всё - не важно, можно по-любому делать и будет легко и просто, а вот когда у вас 20-100 таблиц (да, такое часто бывает), вы будете в них путаться, и используют программы типа такой, которая выше приведена, там сначала рисуют все таблички и связи между ними и уже только потом это переносят в Django или куда-нибудь, и вот тут нужно или грамотно называть классы или же указывать db_table

20-100 таблиц нормально, главное разбивать по логическим приложениям, а называть таблицы самому вполне хорошая практика

тут много новичков, наверное, мне лучше подробнее объяснить: когда проект простой это всё - не важно, можно по-любому делать и будет легко и просто, а вот когда у вас 20-100 таблиц (да, такое часто бывает), вы будете в них путаться, и используют программы типа такой, которая выше приведена, там сначала рисуют все таблички и связи между ними и уже только потом это переносят в Django или куда-нибудь, и вот тут нужно или грамотно называть классы или же указывать db_table

У меня вот аргументы в пользу стандартных имен - это возможность по таблице определить в каком аппе это находиться и наоборот. Т.е. легкий поиск модели в коде и ее соответствие в БД. Но с другой стороны, сейчас вот подумал, что стороннему человеку(например нужна БД для чего-то, какие-то отчеты сделать) будет не опнятно все эти префиксы и будет выглядить странным. Наверное ему будет привичнее без префиксов видеть это. Поэтому задумался сейчас.

Часто бывает база одна, а приложение ее использует не только Джанго. Тогда называть таблицы вручную вообще обязательно.

У меня вот аргументы в пользу стандартных имен - это возможность по таблице определить в каком аппе это находиться и наоборот. Т.е. легкий поиск модели в коде и ее соответствие в БД. Но с другой стороны, сейчас вот подумал, что стороннему человеку(например нужна БД для чего-то, какие-то отчеты сделать) будет не опнятно все эти префиксы и будет выглядить странным. Наверное ему будет привичнее без префиксов видеть это. Поэтому задумался сейчас.

бывает так, что база уже была раньше или базой будет пользоваться не только приложение на Django (это может быть антипаттерном, но так делают)

возможно, Django вам нужна как админка к какой-то другой системе

это, кстати, тоже довольно холиварная тема - кто главнее - Django или Postgres ? для нас кажется очевидным, что Django, а Postgres - зависимость к проекту, но некоторые могут считать иначе ?

я добавляю к названиям таблиц префиксы