kmike

Перешел с Macbook Pro 15" 2008 на Macbook Air 13" 2011.
Просто небо и земля) AIR летает, и разрешения экрана такое же как на Прошке.
Удобно с собой возить, он маленький и очень легкий. Батаря 5-6 часов — просто отлично.
Думаю может еще в будущем докуплю Apple Thunderbolt Display

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

Поменял свою 15 прошку (2009) на MBA 13 (4 gb) несколько месяцев назад. Использую по 8 часов на работе + дома.
Постоянно запущен PHPStorm (nginx, mysql, postgresql, php-fpm), хром с кучей табов и т.д. Иногда запускаю PyCharm. Работает субъективно быстрее прошки на этих задачах.

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

Полностью поддерживаю sadyjka про отсутствие бликов на 13".

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

С моим зрением в 1 на оба глаза 13" вполне нормально. Я пишу на нем код по 3 часа в день (в остальное время есть монитор побольше). Не меняя размеров шрифта. За полгода зрение не упало.

Ни в коем случае не бросайте.

Учитесь и радуйтесь жизни. Студенческие годы — лучшие воспоминания в жизни. Успеете ещё наработаться.
Я считаю, что учиться в серьезном ВУЗе на тех. специальности полезно в среднем — формирует «правильные мозги», точнее аналитический склад ума. А сами полученные знания… да ничтожны

Диплом это показатель, что вы можете заниматься нудной, скучной, не интересной вам фигней в течении длительного времени и успешно.
Таких вот «нудны\скучных\долгих» рутинных «проектов» в вашей жизни может быть еще много.
Диплом показывает работодателю, что вы не бросите задание только по тому, что оно вам наскучило.
Это помимо всего вышесказанного.

У самого, да и у многих моих друзей была такая проблема. Где то на 3-м курсе понял что университет не очень поможет в освоении тех знаний которые меня в тот момент интересовали. Но уже на тот момент я работал, как и мои друзья. Поэтому кто как смог из нас закончили 5-тый курс, при этом активно работая. Да был небольшой бонус: преподаватели (почти все) шли на встречу узнавая что работаю по специальности, даже по большей части мы им показывали много нового и интересного, что не входило в программу обучения. А так совет — постарайтесь окончить университет — много не потеряете, но может еще что-то приобретете, кроме приятных воспоминания и диплома.

Рассматривайте учебу как проект. Вы за него взялись? Найдите силы довести до конца.

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

Мне кажется, надо не усложнять API и возвращать категории товара (их id и название например) вместе с товаром, по ссылке /products/id. А если есть реальная потребность получать какие-то свойства товара отдельно (только цена и описание например), добавьте параметр ?fields=field1,field2

Проектировать API стоит не из каких-то абстрактных соображений, а из планируемых сценариев использования, и из соображений простоты.

Идея написать «написать что-то вроде CMS на очень крутом, на мой счет, фреймворке Yii» порочна изначально.
Дело тут не в желании написать CMS и не в Yii, а в том, что писать CMS имеет смысл когда сформулирована некая идея, зачем эта CMS нужна и чем она будет выгодно отличаться от сотен имеющихся. То, что она будет написана на основе какого-либо фреймворка, отнюдь не решающее достоинство.

Правильной идеей было бы: Хочу написать CMS которая будет реализовывать такие-то принципы, иметь такие-то уникальные фишки, и.т.п. ваша же идея провальна с постановки задачи.

Направление вызовов прежде всего. Фреймворк вызывает ваш код, он как бы внутри его. А библиотеку вызывает ваш код, она внутри его. А требования определенной структуризации и ограничения, упомянутые выше, это лишь следствия, чтобы фреймворк знал что и где вызывать и знал что делать с возвращаемыми значениями.

А можно хотя бы один пример объектов? Лучше один раз увидеть.

> автоматическая сборка статики
django-staticfiles интегрирован в основной фремворк. Теперь ./manage.py collectstatic собирает статику по всем приложениям в одно место. Все конфигурируемо.

> валидация в одном месте (серверная и клиентская)
В стандарном фреймворке нет.

> проблема с пользователями (расширение профиля)
Теперь можно привязать произвольную модель с ссылкой на User как профиль. Хотя и раньше неудобств в этом плане не было, разве нет?

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

И то, и то :)

Как показывает личная практика — возможно заниматься параллельно олимпиадным программированием и вести OpenSource проект, знания получаемые в каждой из этих отраслей взаимодополняют друг друга.

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

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

По-моему основная цель валидации e-mail'ов — защита от опечаток. Все остальное излишне.

Коллективный интеллект пытался породить ее здесь — djangopackages.com/ Проверяю его и гугл перед тем как что-то делать. А «пытался» потому что частенько в гугле находятся apps которые более reusable, чем представленные на том сайте.

Что же касается меня

• Во все свои проекты сразу добавляю South
  
• Для авторизации через соц сети — django-social-auth
  
• Есть проект со всякими мелкими утилитами, django-annoying
  

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