Динамические запросы (фильтры) в django

Хороший заголовок, информации в гугле по этому поводу не найдено. Стоит задача сделать фильтр. Возьмем, к примеру, таблицу, первая строка которой содержит фильтры для колонок. Усложненный вариант фильтра позволяет выбирать сразу несколько значений. Реализовать такой механизм средствами ORM django довольно просто.

Создаем метод, получающий на вход имя поля и массив значений: Вызывать можно таким образом: Обращаю внимание на одну очень замечательную особенность ORM django — city__country__name. Эта запись означает, что мы фильтруем по имени страны, к которой принадлежит город нашей целевой модели. Работу по созданию джоинов джанго берет на себя.

Основываясь на коде, приведенном выше можно построить универсальную систему фильтрации.

Конкурентное приемущество

Поговорим о профессиональной арифметике. Квалификация специалиста сложена из суммы практического опыта и теоретических знаний. Одни добиваются больших результатов, другие — не очень. Отбросив такие факторы как талант и везение, посчитаем время потраченное на практическую работу и освоение теории (пишу пост и самому интересно, что выйдет). Среднестатистический работник, работая 7 (да-да, еще час шарится не по делу) часов в день, за 5 лет отрабатывает = ((7×5*4×12)-(24×7))*5=7 560 часов — формула ((рабочий день*рабочие дни в неделе*количество недель в месяце*количество месяцев в году)-(отпускные дни*рабочий день)) На «внеклассное чтение» он тратит часов 200 (максимум), итого 7760 часов работы. Вероятно, что много времени было потрачено не эффективно, ввиду низкой скорости роста. Теперь возьмем трудягу, допустим, Тему Лебедева. Он говорил, что работал в среднем 10 часов в сутки без праздников и выходных. Поверим ему и посчитаем, его личный результат в часах за 5 лет: (10×7*4×12)*5 = 16 800 часов Допустим, что Тема в день тратил 2 часа на саморазвитие. (2×7*4×12)*5 = 3 360 часов В сумме 20 260 часов. Учитывая то, что Тема почти в три раза больше работал, в 15 раз больше времени потратил на развитие — его один час можно считать за 3 часа работы среднего работника. Выходит, что Тема (хороший работник) через пять лет стал в 9 раз круче того среднего специалиста. Вот вам и конкурентное приемущество, па-ра-па-па-пам-щщьььь

Девочки

Далее список ласкательных, замеченных мной, которые говорят парни своим девушкам:
Животные:

  • заяц, зая
  • кот, котя, кошечка
  • лапа, лапочка (тут кусок животного?)
  • хрюша, хрюшенька

Отдельно стоит:
 — солнце
Съедобные:

  • сладкая
  • конфетка, конфеточка
  • булочка
  • котлеточка

Уменьшительные:

  • крошка, кроха
  • маленькая, малыш
  • девочка
  • малая (огромный процент моих знакомых встречался с малой)

Любовные:

  • милая
  • любимая
  • дорогая
  • родная
  • красавица

Постельные и другие:
когда кончается запас ласкательных слов, в ход идут придуманные слова и мычание.

Считаем чужие деньги

Часто в Киеве можно встретить принципиальных людей-миллионеров. У них есть захудалые дома с участком в разных точках Киева. Дома достались им из советского прошлого. Живут эти люди зачастую бедно. Их дома стоят от полмиллиона долларов. Далее простая арифметика:
Имея на руках 1 лимон баксов, можно иметь спокойно 10% годовых, т.е. иметь в месяц 10 000$, за 2 тысячи долларов можно снять отличную квартиру, остальное можно тратить на вполне безбедное существование.

Анализируя JavaScript код

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

Спрятать и показать

Типичный код, — абсолютно симметричная пара методов для сокрытия и показа чего-то. Но решение не самое лучшее из-за дублирования:

Рефакторим:

Вполне резонно заметить, что получившегося кода стало больше на один метод и не ясно, стоит ли увеличивать комплексность кода. В данном случае экономия весьма не очевидна, как и затраты. Я за то чтобы делать рефакторинг, начиная с самого незначительного — все дело в стиле мышления (не говоря о гибкости, которая появилась). Поддерживая порядок, будешь жить в чистоте. Иначе — известно в чем.

Массивы

Часто можно встретить такой вид создания:

Более короткая версия:

Удаление элемента из массива. Интуитивно-понятного метода remove у массива нет, к сожалению. Поэтому можно встретить код: Тут происходит простое копирование всего в новый массив, за исключением ненужного элемента. Не самый быстрый способ, особенно в случае большого массива. Пользователи библиотеки Prototype.js для этой часто используют метод — arr.without(el), который работает по той же самой схеме (все же замечу, что у прототайпа великолепные методы для расширения класса Array). Тривиально, но многие не знают, что удаление из массива выполняет встроенная операция — arr.splice(номер элемента, количество удаляемых элементов) — еще метод позволяет делать замену.

Создание элементов

Часто можно увидеть большое количество кода создающего DOM-структуру. Пишутся обертки для удобного создания DOM-елементов. А ведь решение — не самое производительное.

По производительности innerHTML — лучший. Исходя из этого, в большинстве случаев методы DOM отбрасываем (есть исключения, такие как тег — table в IE, он не дает ничего записать в свой innerHTML). Мне очень нравится класс Template в библиотеке Prototype, позволяющий создавать штмл подобным образом: Для остальных пользователей легко придумать решение используя стандартный replace. Еще на один момент следует обратить внимание. Временным контейнером штмл является массив строк и в конце происходит this.cbCity.innerHTML = options.join(""); — это дает лучшую производительность.

В заключение

Мне еще попадались различные стандартные ситуации. По мере возможности, в будущем соберу их еще в одну часть.

Все, созерцаем

Внедрил типограф — наслаждаюсь елочками и длинными тире.

Антонимы

Нельзя — Льзя

Инвестиции

Давно не постил на тему банальных вещей. Самые лучшие инвестиции — в здоровье и знания.
(пишу и сомневаюсь, правильно ли построены предыдущие два предложения (и это тоже))

Русский язык

Всегда подозревал, что знаю его не очень хорошо. И вот недавно понял, что таки вообще его не знаю. Я в ужосе.

Предъявляем билетик

Путешествуя общественным транспортом, был недавно проверен на наличие билета контроллером (я по привычке купил и пробил билет, так что все ок). Причем, на маршруте, который бдители никогда не посещали. А сегодня услышал, что транспортники активно набирают контроллеров на зарплату 3500–4000 грн. Настали зажиточные времена у транспортников.
Еще оказывается, в киоске талончики можно купить за полторы гривны, а не за две, как внутри.

Симметрия кода

Прочитал книгу Кента Бека «Implementation Patterns», у нас почему-то названную «Шаблоны интеграции корпоративных приложений». Коэффициент полезного содержания в этой книге, по какой-то причине, оказался меньшим чем я рассчитывал (возможно, прочитанное будет вылазить из недр сознания позже).

Тем не менее, мысль о симметрии в коде, мне понравилась. Возможно, термин «однородность кода» ходит где-то рядом.

Симметричный код читать легче. Например, зная один метод, можно предположить, что ему есть пара: enable, disable; add, remove; undo, redo и так далее. Симметричность может проявляться не только в именах-антонимах, но и в логике кода.

Возьму книжный пример (вдобавок мое вольное изложение на основе воспринятого): Код не симметричен: count++ дает слишком много детализации по сравнению с input и output. Теперь более симметрично. Но ввод, увеличить количество, вывод — не самые симметричные вещи. Куда однороднее звучит — ввод, счет, вывод.

Теперь попробую применить к своему коду (внимание, эксперементальный юмор):

Джаваскриптовый метод, создающий штмл для вывода городов в выпадающем списке.

Подозреваю, с точки зрения симметрии не самый лучший код, попробую его улучшить (выношу инициализацию, выношу заполнение, делаю обновление списка):

Промежуточная версия кода была бы куда менее близка к симметрии:

А вот финальная версия, с точки зрения детализации, является симметричной:

Любимые продукты

Люблю кефир «Галактон», орешки «Felix», грейпфруты «Jaffa»

Все умрут, а я останусь

Четкий фильм. Режиссер — молодец. Прям как из детства.

Юнит-тестирование — плохо

Для не знающих

Вы попробовали тестирование и поняли, что ваш случай в корне отличается от того, что в книге. Ваши сроки из реальной жизни, у вас нет времени еще и тесты писать. Поддержка тестов только замедляет разработку. Какой толк, все равно та либа работает только на том сервере, а локально нет.

Но

Вы, скорее всего, не умеете писать тесты и, очень вероятно, что в вашем коде присутствует большинство признаков плохого кода. Это лечится при желании. Лекарства:

  • Рефакторинг. Улучшение существующего кода
  • Экстремальное программирование: разработка через тестирование
  • Шаблоны тестирования xUnit. Рефакторинг кода тестов — эта книга мега-лекарство.

Для знающих много пользы

А знать надо вот что:

  • Юнит-тест — тестирует лишь небольшой кусочек функционала.
    В идеале протестировать метод на то, что он правильно делает вызовы других методов
  • Юнит-тест невероятно быстр.
    Поскольку тестируется лишь маленький кусочек функционала без обращений к бд или файлам — все довольно таки быстро.
  • Для большого метода юнит-тест написать очень сложно.
    Сложно, потому что много логики. Приходится слишком много заглушек делать для одного метода.
  • Тестируемый функционал не обращается к базе данных, не отправляет запросов, не считывает файлы с диска.
    Это долго и тестируемый функционал становится незащищенным от сбоев внешнего функционала.
  • Юнит-тест не зависит не от порядка выполнения теста, не от сбоев в остальном функционале.
    Тесты должны быть независимы — это упрощает локализацию ошибок.
  • Все юнит-тесты вместе взятые выполняются не более 10 секунд в любом проекте.
    Иначе слишком часто запускать их будет не удобно.
  • Юнит-тесты как и код требуют рефакторинга.
    Постоянно делая рефакторинг, получите свой тестовый язык (или апи) для тестов.
  • 100% покрытие юнит-тестами не даст 100% гарантии работоспособности проекта.
    Всего не учтешь и не протестируешь.
    Тесты дадут возможность:

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

Еще мысли

Юнит-тесты писать сложно. Лень, незнание, самообман — очень веские помехи.
Разработка через тестирование? — В идеале.
Легко тестировать функционал для рассчетов чего-либо — это сплошное удовольствие.
Являются ли тесты гарантией успеха проекта? — Нет, также как и хороший код. Но приятнее работать с хорошим кодом и с протестированным функционалом.
Если проект не большой и его не надо будет сопровождать в будущем — можно и без тестов обойтись, используя копи-паст для ускорения разработки.

Кроме юнит-тестов нужно писать интеграционные тесты — те же юнит-тесты только без заглушек функционала. Выполняются долго, зато позволяют проверить, что механизм в собранном виде функционирует нормально.

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

И обязательно прочтите книги из списка, если еще этого не сделали.

Изменения

Решил немного изменить внешний вид блога 

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

Еще хочу переделывать дальше — чувствую от fnice шаблона, ничего не останется.

Сводка проишедствий

Вчера на Харьковском шоссе возле Ленинградской площади лежала отрезанная треть машины — видимо опять было лобовое столкновение. Сколько людей уже полегло на этом шоссе?
В метро Палац Спорта стал свидетелем поимки вора. Чувака держало 4 других злых чувака и почти начали его бить. Вор пытался убежать, но ему не дали.

Жизнь после жизни

Многие верят в загробную жизнь, перерождения, уход в другую реальность и так далее.
Расскажу во что я верю, наивно полагая, что мои примитивные мысли (в масштабе вселенной) содержат в себе логику. Можно воспринимать это как философствования.
Человеческий мозг состоит из множества нейронов, которые в процессе развития мозга создают связи между собой. Человек начинает мыслить. Вместе с этим возникает ощущение своей важности для мира, времени, вселенной. Но это только ощущение — для вселенной любая жизнь и даже любая тысяча или миллион лет — всего лишь мгновенье, переход энергии из одного состояния в другое.
Я считаю, что любое существо — временное состояние энергии. После смерти существа энергия переходит в другие формы, более простые.
Душа — можно верить, что она есть, кто-то даже может сказать, что видел ее.
Бессмертие души или перерождения — эти предположения весьма эгоистичны. Ведь тяжело осознать, что эта жизнь уникальна и конечна, а после смерти ничего нет. «Ничего нет» — представить нереально, а вот «что-то есть» представить не так уж сложно. И даже очень хочется верить в то, что после смерти это мыслящее, что внутри нас, осталось и существует еще где-то. Но думаю, что для вселенной (Бога?) мы слишком малы, чтоб подобный сценарий был правдой.

Не тешьте себя иллюзиями людишки! Ха-ха-ха-ха!

Кстати, если кто-то считает, что я не верю в религию — он прав. В Бога я верю, и не требую от него ничего, радуясь тому, что у меня есть жизнь.

Зубы

Берегите зубы!
Сожрав сладкое, сполосните рот водой. В сладкой среде микроорганизмы хорошо живут.
Сожрав кислое, не жрите сухари и не чистите зубы щеткой. Сполосните водой с содой и ок.
Зубы 2 раза в день чистите, со всех сторон.
У меня в 23 года ни одной пломбы не травматического характера (спортивные травмы покоцали малек передок). Но годы идут, появились первые претенденты на пломбировку, буду лечить.
Подозреваю это связанно с тем, что последний год не жру творог регулярно, так как делал большую часть жизни.
А еще ненавижу когда во рту запах пыли ткани зуба.

Вода

Получаю истинное наслаждение, выпив прохладной воды, после того как поел соленое.

Идеальный начальник

Порассуждаю на тему начальника:

  • Искренний. Часто подчиненные не верят начальнику по причине, неискренности. Они слушают и думают, а что это изменит?
  • Последовательность. Непоследовательного начальника не уважают, и не воспринимают всерьез его слова.
  • Смирение. Любой положительный замысел начальника может захлебнуться при попытке донести его до подчиненных — слышны будут лишь самовосхваления и поучения.
  • Справедливость, в том числе по отношению к себе. Несправедливый начальник будет винить кого угодно только не себя.
  • Квалификация. Идеальный начальник должен быть экспертом своей области и быть способным выполнять работу троих своих непосредственных подчиненных вместе взятых.
  • Безудержное желание сделать лучше. Если начальник не тянется вверх, скорее всего никто другой не потянется.
  • Доброта. Со злым человеком работать не приятно.

пс стоит ли говорить, что я хочу быть идеальным начальником)

Постановка задач

Заказывая работу или ставя задачу, всегда нужно проверить исполнение работы — это закон. Хороший результат можно получить лишь проверяя дотошно результат чужого труда.
Я так всегда делаю — не доверяю никому, даже себе.

Шкаф

Сколько хожу по всяческим гос структурам, практически везде вижу совковый шкаф с заклеенными бумагой стеклами.
шкаф
Это я был в паспортном столе. Наконец, получил паспорт. История началась тут.

Неделю назад ел

Люблю малину. Для меня — одна из самых вкусных и красивых ягод.
малина ежевика