Egorian

Предположу, что в модели ChatRoom есть many-to-many поле с именем users:

from django.urls import resolve

class MessageInline(admin.TabularInline):
    model = Message

    def get_user(self, request):
        resolved = resolve(request.path_info)
        if resolved.args:
             return self.parent_model.objects.get(pk=resolved.args[0])
        return None

    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "chat_room":
            user = self.get_user(request)
            if user:
                kwargs["queryset"] = ChatRoom.objects.filter(users=user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

Я тоже периодически задаюсь этим вопросом. И вот что я надумал:

1. Это, безусловно, опыт. Причем опыт на самых разных уровнях: знание языка и библиотек (SDK, интерфейсов, да хоть список аргументов функций). Опыт проектирования классов - раньше сидел, думал как лучше спроектировать взаимодействие классов, что где разместить и т.п, по 10 раз все переписывал. Сейчас же, прочитав книжки про паттерны, проектирование в общем - структура выстраивается сама собой (я даже не буду упоминать про важность сего при рефакторингах и т.п.). Опыт проектирования целых "подсистем" - например, если ты делал сервис тех-поддержки, или интернет-магазин, то во второй раз ты сделаешь его гораздо быстрее, у всех все примерно одинаково.

2. Опасность веб-разработки (точнее, скриптовых языков) - это "легкость тестирования". Как то я общался с другом - он был веб-разработчиком и переквалифицировался на десктоп. Он говорил, что одна из особенностей в том, что в вебе ты можешь изменить строку, открыть браузер, и просто обновить страницу - ты сразу увидишь результат. В десктопе (а точнее - компилируемых языках) - у тебя пройдет кучу времени, прижде чем проект скомпилируется, поэтому пишешь совсем по другому - много пишешь, потом разом все тестируешь и дебажишь.

И это такой подход действительно гораздо продуктивнее. Сейчас я могу писать по несколько часов, а иногда и дней, и не разу не "обновить страницу" или запустить тесты. А потом разом все отдебажить - поверь, так гораздо быстрее получается. Единственное - такой подход возможен "при опыте", когда ты знаешь как и что писать.

3. Согласен с предыдущем высказыванием - это интерес. То что интересно - действительно можно пилить сутками (но не до фанатизма - это всегда боком выходит). С этой точки зрения хорошо работать в крупных компаниях - там задачи на любой лад. Мой пример из жизни - я сервреный программист, люблю все эти сложные хитросплетения серверных технологий, базы данных, очереди, шардинги и прочее, но... ненавижу фронтенд, ей богу. Не то чтобы не могу, просто очень не люблю. И последне несколько лет, работая в СПб, мне практически не приходилось сталкиваться с фронтендом, но пришлось переехать в маленький город, где с крупными компаниями проблема, устроился в одну контору фуллстек'ом, и когда въехал в проект, понял что там фронтенда очень много, и делать надо преимущественно его. Итог - просрал все сроки, подвел хороших людей, предложил уволить меня так как я им не подхожу, ну меня и уволили. Печальная история. Как вывод - занимайся тем, что нравиться.

4. Тут еще много всего - начиная от быстрого печатания, отсутсвие постоянных переключений между задачами, заканчивая удобной IDE и ос (например, лично для меня на маке оказалось гораздо удобнее работать чем на винде).

Но все-же, прежде всего опыт. Опыт работы над крупными и сложными проектами - на мелких мало чему научишься. И книги. И дисциплина - делать как надо, а не быдлокодить - ибо потом баги и рефакторинг сожрет в десть раз больше времени. В прочем, чтоб не быдлокодить, надо еще понимать "как правильно" - это опять книги. 4 месяца - это мелочь, за это время нельзя научиться хорошо программировать. Так что вот для начала - www.ozon.ru/context/detail/id/5508646 . Когда хорошо освоишься и получишь опыт - вот про паттерны www.ozon.ru/context/detail/id/20217137/. Ну а когда поработаешь над крупными проектами, и поймешь какая обычно жопа у них с бизнес логикой - то вот www.ozon.ru/context/detail/id/5497184

На счет времени - у меня получается с головой окунаться на 4 часа, потом требуется отдохнуть час-два. Отдохнуть - не значит заниматься совсем другим, можно просто переключиться на более простую задачу, рутинную, не требующую супер-концентрации. Потом можно снова концентрироваться. Но у каждого по своему - здесь нет стандартов.

На счет концентрации, как ее добиваться: Года 2 назад я был на Найти-ИТ, там выступал один из основателей Рексофт'а, леция называлась что то типа "Легкий путь из программиста в бизнесмене" - пожалуй, самая мудрая лекция, которую я когда-либо слышал. Он очень рекомендовал книгу "Поток" www.ozon.ru/context/detail/id/6233608/. 2 года я все хотел ее прочесть, недавно прочел - потрясающая книга. Там все ответы на твои вопросы по концентрации, и не только.

Вот еще хорошая книга, которая затрагивает поставленные тобой вопросы - www.ozon.ru/context/detail/id/2338486

Вопрос далеко не простой. Если прогнать через jsbeautifier.org и убрать шум, то останется такой код:

(function(){

function ExitApi () {};
  
ExitApi.prototype.exit = function() {
   console.log("Exit API: Close requested.")
};

ExitApi.prototype.delayCloseButton = function(e) {
   if (e < 5) e = 5;

   console.log("Exit API: Close Button will not appear for " + e + " seconds.")
};

var b = new ExitApi(),
   method = "ExitApi",
   _this = this;

if (!method in _this && _this.execScript) {
  _this.execScript("var " + method);
}

if (!_this[method] || _this[method] === Object.prototype[method]) _this[method] = ExitApi;

}).call(this);

_this в данном случае скорее всего объект window или аналог.
Если оставить только суть, то она приблизительно такова:

(function(){

function Foo () {};
  
Foo.prototype.exit = function() {
   console.log("Exit API: Close requested.")
};

Foo.prototype.delayCloseButton = function(e) {
   if (e < 5) e = 5;

   console.log("Exit API: Close Button will not appear for " + e + " seconds.")
};

this.ExitApi = new Foo();

}).call(this);

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

конечно - на сайте mongodb

…Одним из примеров громоздкой и, по мнению авторов, бесполезной надстройки является интегрированная система WINDOWS фирмы Microsoft. Эта система занимает почти 1 Мбайт дисковой памяти и рассчитана на преимущественное использование совместно с устройством типа мышь…

…Таким образом, читатель уже понял, что среди надстроек над ДОС бывают довольно бесполезные системы, которые только выглядят красиво, а на самом деле отнимают время пользователя, память на дисках и оперативную память ЭВМ. Обманчивая красота таких систем, однако, сильно воздействует на неискушенных пользователей, которые не имели практики работы на машине. Инерция мышления бывает столь сильна, что авторам приходилось наблюдать, как люди, начавшие работать с подобной настройкой, впоследствии с трудом заставляют себя изучать команды ДОС… Хочется предостеречь от этой ошибки читателей…

"Персональные ЭВМ в инженерной практике", 1992

#something выпадает из потока потому что ему дано свойство position. Прежде чем его применять изучите теорию