Обновить
346
Коробов Михаил @kmikeread⁠-⁠only

Пользователь

Отправить сообщение
Вы почему-то считаете, что критерий правильности — это как происхождение слова. Это не так. Единственный критерий правильности в русском языке — это соответствие языковой норме. Никто не пишет Ландан (Лондон), Чечил (Черчилль) и тд. Если название Ява стало общепринятым, то оно является правильным, чего уж тут поделаешь.
Спасибо за ссылку на django-geonames, там и часовые пояса, и привязка к GeoDjango есть, оказывается :)

В модели «город» еще обычно удобно иметь какие-то методы для работы с датами: текущее время, например.
Вы меня об этом спрашиваете?) Если «стабильность» — это отсутствие багов, то, думаю, с ней примерно так же, как и в 1.2.4. Баги могут быть, но и без «альфа» они могут быть. Насчет API — API у фиксированного коммита из репозитория меняться не будет) Если там есть нужная фича, то брать и использовать, делать-то что. Ставьте версию из репозитория и вперед, если что-то не так — обновляетесь до последней ревизии, правите и pull request. По опыту, «житье» на последних ревизиях софта с учетом того, что что-то, возможно, придется поправить — вполне рабочий подход, да и код, который используешь, в любом случае читать полезно (для маленьких штук — всегда весь читаю, вдруг там фигня какая-то, для больших — основной хотя бы). В проекте сейчас где-то 80 сторонних пакетов используется, из них десяток — это фиксированные ревизии из репозиториев на битбакете и гитхабе — для тех, где есть незарелизенные багфиксы или улучшения какие-то, важные для конкретного проекта.
Качаем последнюю версию django-modeltranslation.

Распаковываем, заходим в распакованный каталог и устанавливаем python setup.py install.

Можно сразу из распакованного каталога руками закинуть в папку для статических файлов директорию modeltranslation/static/modeltranslation.


Лучше ставить через pip и использовать django.contrib.staticfiles.
а haystack второй не поможет? там вроде как поддержка нескольких индексов одновременно есть
Библиотечка полезная может быть, если нужно от БД отвязаться для каких-то сложных запросов, с месяц назад заметил на гитхабе ее.

А вот срач достал очень, понты все эти, кто какой крутой питонщик и кто какой крутой джангист, провокации, вторые смыслы у вроде бы технических статей, манипуляции, комменты в духе ты дурак, т.к. пишешь на пэхэпэ (варианты: на джанге, на питоне, не на ерланге, не знаешь haskell и т.д.) а я д'Артаньян и тд., не стоят технологии того. Повод поворчать и поругать код всегда найти можно: вот прикручивал я WebTest из Pylons к django — штука хорошая, что получилось — нравится. И что, нужно было что-ли писать статью «джанго — дерьмо, и даже тест-клиент у него дерьмовый, а вот в пилонсе все круто» или «ну и дерьмо же ваш пилонс, парсинг html на регэкспах, причем неправильный, юникод не поддерживается совсем, весь код в одном файле на 50k и полторы тыщи строк, столько всего исправить пришлось, прежде чем хоть как-то пользоваться можно стало, и вообще, у WebTest с пилонсом интеграция сейчас хуже, чем с джангой, клево да». Ну кому все это нужно, желтизна эта и срач, ну весело, конечно, было бы, типа вот кашу заварил а эти хомячки комментируют, и даже на мнение людей о технологиях повлиять можно, но блин, не несет срач пользы человечеству. Люди не идиоты, если технология хорошая и понятно, почему, то ей будут пользоваться. А вот когда пытаются описать преимущества технологии через «опускание» конкурентов, это всегда настораживает. Мне это в джанге очень нравится — в рассылке вот недавно было предложение на главной написать, что, мол, джанго, крутая штука и у нее куча преимуществ по сравнению с другими технологиями, реакция человека ответственного за это (Jacob Kaplan-Moss) — «только через мой труп» («only over my dead body»): если и говорить о достоинствах, то говорить предметно, без срача и неуважения к подходам других программистов. Угу, набегайте теперь и пишите, что у джанги нет достоинств по сравнению с другими технологиями, подтверждая все вышенаписанное.
С техническими терминами ведь такая штука, они означают что-то конкретное. А в обычном языке, на котором все разговаривают, слова очень часто имеют множество значений, оттенков, каких-то связей и ассоциаций. Что хуже, иногда и технические термины имеют множество значений (но конкретное значение обычно понятно из контекста хотя бы). Поэтому в науке так много неологизмов — это удобно, т.к. при использовании неологизма термин не засоряется «мусорным» наследием обычных слов. Иногда, конечно, удается найти хорошее сочетание слов, передающее суть и не мешающее своими призвуками (или помогающее), но тут, как мне кажется, случай не тот.
Никак бы не перевел, а то напереводят терминов, все причем по-разному, потом сидишь гадаешь и обратным переводом занимаешься. Ну в духе «передача состояния представления» — чего-чего? А что, любая передача состояния представления («представление» имется в виду из MVC? или нет? передача — по сети? или передача другому объекту? или передача словами?) — это REST? И с другими вариантами то же самое. Это же все ухудшает понимание текста, а не улучшает. Ладно бы нормальный устоявшийся перевод был, который все понимают более-менее, а то тут его нет. Предложенные варинты — какой-то ужас, наборы слов, которые в зависимости от контекста можно трактовать кучей способов. Если очень нужно где-то перевести для галочки (ну бывает, формальности всякие), переводить как угодно, в скобках, и не париться. А если необходимости нет — пожалейте читателей, это в лучшем случае информационный мусор получится, а в худшем — ребус на ровном месте.
Вы почему-то считаете, что выкладывать код в open-source программисту невыгодно, что это какой-то акт самопожертвования) Это выгодно и интересно. У меня после того, как стал выкладывать код в open source, з/п выросла раз в 10, HR'ы интересуются постоянно (например, на прошлой неделе в фейсбук звали поговорить, и так и написали, что их заинтересовал мой крайне небольшой вклад в python-фреймворк tornado; постоянно предложения разные идут), и причинно-следственная связь тут прямая: код — это резюме + тебя уже более-менее знают, если твоим кодом пользуются, это стабильность и уверенность. Эти очевидные плюсы для разработчика — помимо того, что это все интересно, полезно для саморазвития (т.к. учишься смотреть вокруг и слушать других людей), полезно для окружающих, всего человечества, да и просто приятно. Если код пишешь для какой-то фирмы, то и для фирмы тоже полезно в open-source выкладывать разные штуки, т.к. со своими open-source проектами проще найти разработчиков (часть людей с частью кодовой базы уже знакомы, отношение к компании тоже лучше) + есть помощь от коммьюнити.

Конечно, ситуации разные бывают, и я больше варюсь в веб-разработке, где конечные продукты тиражируемы слабы, и в open source выкладываются штуки от программистов для программистов, но все же для хорошего провинциального неустроенного программиста я вижу больше предпосылок увлечься open source, чем для устроенного в жизни московича (при прочих равных), хотя, конечно, от человека зависит, и от ситуации, + если это не интересно делать просто так, то смысла ровно 0 этим заниматься.
Вас никто, конечно, не должен считать негодяем, и со своим кодом Вы имеете полное право делать все, что угодно.

Но постараюсь разъяснить все же немного позицию противоположную: если человек отдал зарплату за 4 года, то у него больше нет зарплаты за 4 года. Если человек открыл исходники, то у него исходники остались и он может продолжать делать с ними все, что угодно. Кроме того, появляются дополнительные плюсы: при условии достаточного качества этих исходников и их полезности/интересности (в постиндустриальный век имеется тенденция к тому, что писателей больше, чем читателей — впрочем, в IT пока это особых проблем не создает) можно просто так получить помощь в разработке, проверку в различных условиях, выявление скрытых багов. Пополнение словаря и шаблонов, в конце концов, чтоб мощности хватало.

Это все не говоря о пользе для человечества) Надоест Вам делать эту программу, останется только на 80% работающий экзешник, демка, которая никому не нужна, разве что поставить раз, сказать «вах», закрыть и больше не запускать никогда, сколько проектов так умерло — а при открытом с самого начала коде с либеральной лицензией может и пригодится кому-нибудь, может что-то из этого вырастет, и не одно.

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

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

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

Наверное, тут еще такая штука — тут много программистов и люди от поста из хабре ожидали узнать что-то полезное, а увидели описание демки, от которой им ни тепло, ни холодно.
Ага, вход через соц. сети проблему решает, о чем я вроде бы написал? Если человек гарантированно может авторизоваться другими способами (кроме пары email+пароль), то подтверждение ящика не нужно.

Насчет «уверен, что не забудет пароль» — с точки зрения сервися это ведь проблема не самого человека, а скорее службы поддержки (особенно если есть какие-то финансовые отношения), + доп. простор для соц. инженерии. Все уверены, что не забудут.

Ну как, пока гром не грянет, мужик-то не того.
Тут, думаю, мораль не в конкретных фразах, а в том, что от заголовка письма зависит очень многое и что правильный заголовок можно определить с помощью A/B тестирования. Задним умом-то все сильны, но вот заранее сказать, что сработает, а что нет, и какая будет разница — очень сложно, все лучше проверять и иметь цифры на руках, а не гадать.
Смотрите, пусть мы хотим сделать регистрацию логин+пароль. Чтоб человек мог восстановить пароль, мы должны спросить у него email, иначе при забытом пароле аккаунт просто теряется навсегда (возможно, с какой-то ценной для человека информацией внутри). Получается, что нужны и логин, и пароль, и почта. Становится непонятно, зачем тут логин — убираем его и получаем регистрацию почта+пароль. Чтобы удостовериться, что человек сможет восстановить свой аккаунт, нужно знать, что почта рабочая и человек сможет прочитать письмо в ней, поэтому ее просят подтвердить.

Если этого всего не делать, то многие пользователи не смогут восстановить свой аккаунт, если забудут пароль. Это не обойти никак — всегда нужен какой-то канал связи с пользователем на случай проблем. «Большие» могут позволить себе использовать смс, но массовым это пока не стало. OpenID и всякие входы через твиттер/вконтакте/мейлру/фейсбук эту проблему тоже решают (т.к. там не нужен пароль и забывать нечего).

Но если регистрация «классическая», то подтверждение email'а — необходимость, вне зависимости от желания владельцев сайта заспамить своих пользователей. Убрать его нельзя, подтверждение почты нужно для безопасности пользовательских данных внутри аккаунта.

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

Т.е. понятно, что призывы сделать почту необязательной или сделать подтверждение почты необязательным всегда будут пользоваться популярностью (как и точка зрения о владельцах сайтов — спамерах-злодеях), но этот вариант хуже варианта с подтверждением; правильное решение этой проблемы — это вход через OpenID/соц. сети, подтверждение через смс (хотя уж лучше я бы почту сказал сайту, чем телефон) или убирание регистрации совсем.
Не знаю, а зачем скачивать переводы с transifex?
Там никто не переходил, а скорее наоборот: КупиКупон уже был большим и на друпале, когда купил НадоВместе, выкидывать свой движок и менять команду разработчиков они не стали, тут их вполне можно понять, технологии — это далеко не все.

Мы в итоге с их программистами посидели и аккаунты джанговских пользователей в друпал проэкспортировали, НадоВместе поработал потом еще пару месяцев в полузакрытом режиме (пока срок действия всех купонов не закончился — ну чтоб люди распечатать их могли), и тогда уже редирект сделали окончательно.
похоже, разобрались, теперь все не на гитхабе и Зед сам коммитит
Ну даете. Зря, конечно, но простите уж, не сдержусь. Люди много лет писали хорошую штуку и сделали чуть ли невозможное[1], а вас прогресс не радует, а бесит, авторы мол пишут поверхностный бред без глубокого изучения материала, достижения у них смехотворные, а то, что они в своем блоге, посвященном разработке pypy, делятся новостями о различных недавно реализованных оптимизациях (с примерами, конечно), почему-то воспринимаете как «эпопею» и личное оскорбление, при этом самой статьи не читаете и сутью не интересуетесь.

[1] изначальные прикидки были — нуу интерпретатор питона на питоне раз в 500 медленнее будет, чем интерпретатор питона на C — а теперь интерпретатор уже раза в 4 быстрее, чем C-реализация (втч за счет совокупности большого числа оптимизаций — примерно такого рода, как в статье описана), используется в крупном продакшне (quora.com — на pypy крутится), при том, что работало над ним гораздо меньшее число людей, чем на C-версией — на питоне хитрые штуки реализовывать можно с меньшими трудозатратами программиста
А они с Зедом-то уже разобралисьчто-ли? Там же какая-то жесть была (см. news.ycombinator.com/item?id=1874271, репозиторий снесли уже).
Мне кажется, проблемы начинаются тогда, когда защищенный код написать сложнее, чем дырявый (например, это так на «голом» php). В таких случаях нужно постоянно держать уязвимости в голове, легко что-то упустить. Это если вообще задумываться.

C этой точки зрения очень нравится подход явного отключения защиты, а не включения (когда дырявый код написать сложнее, чем защищенный). Например, это так в django и tornado — в шаблонах все экранируется по умолчанию (когда нужно вывести голый html, экранирование нужно явно отключать); orm экранирует sql; если забыли в POST-запрос включить csrf-токен (например, тегом при рендеринге формы, или заголовком браузера для ajax), то по умолчанию все упадет с ошибкой 403 (когда проверка на csrf не нужна — хук для api, например, то ее нужно явно отключать).

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

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность