Frontender Magazine

Необходимый минимум для фронтенд-разработчика

На днях я подготовил описание README для одного проекта, который, надеюсь, будет интересен и поучителен для других разработчиков. Так вот, когда я его писал, я понял, что несколько лет назад испугался бы до смерти, если бы наткнулся на нечто подобное, со всякими упоминаниями о Node и его пакетном менеджере, системах Homebrew и Git, всевозможных тестах, тестовых и финальных сборках.

Когда-то основная часть рабочего процесса фронтенд-разработчика состояла в редактировании файлов, их локальном тестировании (в меру возможностей) и пересылке на сервер через FTP. Мы измеряли свою крутость умением подчинить своей воле IE6 или добиться пиксельного соответствия в различных браузерах. Многим членам нашего сообщества — и мне тоже — не хватало опыта традиционного программирования. HTML, CSS и JavaScript — обычно в виде jQuery — осваивались самостоятельно.

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

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

Вот некоторые вещи, с которыми хотелось бы, чтобы все были знакомы и некоторые источники, которые можно использовать, чтобы подтянуть свои навыки. (Спасибо Полу Айришу (Paul Irish), Майку Тейлору (Mike Taylor), Ангусу Кролу (Angus Croll) и Владу Филипову (Vlad Filippov) за их вклад.)

JavaScript

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

Это значит, что вы прочитали «JavaScript: Сильные стороны», желательно больше одного раза. Что вы понимаете принцип работы структур данных вроде объектов и массивов; функции, в том числе как и почему их нужно вызывать и применять; умеете работать с наследованием через прототипы; и можете справиться с асинхронностью.

Если ваши навыки работы с простым JavaScript оставляют желать лучшего, вот некоторые ресурсы, которые вас выручат:

Система управления версиями файлов Git (и профиль на GitHub)

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

Хотите повысить свои навыки работы с Git?

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

Те дни, когда управление зависимостями сводилось к добавлению дополнительного скрипта или тега стилей на страницу, давно прошли. Даже если у вас не было возможности внедрить замечательные инструменты вроде RequireJS в процесс разработки на работе, вам стоит найти время изучить их в своем личном проекте или проекте вроде Backbone Boilerplate, так как преимущества, которые они в себе несут, трудно переоценить. RequireJS, в частности, делает возможной разработку с использованием небольших модульных файлов JS и CSS, а затем конкатенирует и минифицирует их с помощью своего инструмента оптимизации для дальнейшего использования.

Скептически настроены относительно разработки на основе модулей? Это не причина ничего не делать. По крайней мере, вам должны быть знакомы инструменты вроде UglifyJS или Closure Compiler, которые грамотно сжимают ваш код, а затем конкатенируют эти сжатые файлы перед выдачей результата.

Если вы пишете на чистом CSS - то есть не используете препроцессор вроде Sass или Stylus – RequireJS также поможет организовать ваши CSS файлы по модульному принципу. Используйте операторы @import в основном файле, чтобы загрузить зависимости для разработки и затем запустите средство оптимизации RequireJS для основного файла чтобы создать готовый для использования файл.

Инструменты разработчика, встроенные в браузер

За последние несколько лет инструменты для разработчиков, встроенные в браузеры, ощутимо усовершенствовались и теперь они могут существенно улучшить ваш опыт разработки, если вы научитесь ими правильно пользоваться. (Подсказка: если вы все еще отлаживаете код, используя alert, вы зря убиваете время.)

Вам наверняка стоит выбрать один браузер, чьи инструменты разработчика вы будете использовать на постоянной основе — на данный момент я склоняюсь к инструментам разработчика в Google Chrome - но не отказывайтесь полностью от инструментов в других браузерах, так как в них время от времени на основе откликов разработчиков добавляются новые полезные возможности. В Dragonfly от Opera, в частности, были добавлены некоторые возможности, выделяющие её инструменты разработчика на фоне других, например: (экспериментальный) CSS- профилировщик, настраиваемые горячие клавиши, удалённая отладка без необходимости USB-подключения, а также возможность сохранять и использовать пользовательские цветовые палитры.

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

Командная строка

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

Если какими-то командами вы пользуетесь особенно часто, отредактируйте свой .bashrc, .profile или .zshrc (или что у вас там) и создайте для них альтернативные имена чтобы не набирать команды руками каждый раз. Также можно добавить альтернативные имена в файл ~/.gitconfig. Файлы с точками от Джанни Чиаппетта (Gianni Chiappetta) могут послужить отличным источником вдохновения.

Примечание: Если вы пользуетесь Windows, я не знаю, как вам помочь, разве что могу посоветовать Cygwin. Возможно, я не прав, но принимать участие в жизни сообщества фронтенд-разработчиков с открытым кодом на машине с Windows существенно сложнее. Если посмотреть на вещи оптимистически, ноутбуки MacBook Air не очень дорогие, мощные и на удивление портативные, кроме того существуют Ubuntu или Unix.

Шаблонизация на стороне клиента

Не так давно для серверов было обычным делом отвечать на запрос XHR фрагментом HTML-кода, однако за последние 12-18 месяцев сообщество фронтенд разработчиков прозрело и начало требовать данных от сервера в чистом виде. Преобразование таких данных в HTML, который затем можно добавить в дерево документа, может оказаться трудоёмким и неудобным процессом, если иметь дело непосредственно с кодом. Вот когда в дело вступают библиотеки шаблонизации на стороне клиента: они позволяют использовать шаблоны, которые после добавления данных превращаются в строку HTML. Вам нужна помощь в подборе инструмента для шаблонизации? Схема для выбора шаблона от Герен Минс (Garann Means) поможет вам найти подходящий.

CSS-препроцессоры

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

Тестирование

Одна из радостей написания модульного, свободно сопряжённого кода состоит в том, что такой код намного легче тестировать, а с инструментами вроде Grunt, подготовка проекта со встроенными тестами вообще стала проще простого. В Grunt интегрирован QUnit, однако существует много фреймворков для тестирования, из которых вы можете выбрать те, что вам по душе — моими любимыми на данный момент являются Jasmine и Mocha — в зависимости от стиля, который вы предпочитаете, и остальных составляющих вашей подборки.

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

Автоматизация процессов (rake/make/grunt/и т.д.)

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

Уже довольно давно нам в этом помогают инструменты вроде make, кроме него существуют также rake, grunt и другие. Если вы хотите автоматизировать выполнение заданий связанных с файловыми системами, исключительно полезно будет изучить язык, отличный от JavaScript, так как асинхронная природа Node может стать неподъемным грузом, если вы умеете только управлять файлами. Существует также множество других инструментов автоматизации, созданных под конкретные задачи: инструменты для развёртывания, генерирования сборки, проверки качества кода, и др.

Качество кода

Если вам когда-либо приходилось ощущать негативные последствия от пропущенной точки с запятой или лишней запятой, вы знаете сколько времени можно потерять из-за мелких ошибок в коде. Поэтому вы пропускаете свой код через инструмент вроде JSHint, верно? Он поддаётся настройке и может быть интегрирован в ваш редактор или процесс сборки несколькими способами.

Хорошее руководство

К сожалению, руководства по фронтенд-разработке не существует, однако ресурс MDN вполне подходит на эту роль. Хорошие фронтенд разработчики знают, что в каждый поисковый запрос нужно добавлять префикс mdn — например, mdn массивы javascript — чтобы избежать коммерческой чумы, которой является ресурс w3schools.

Конец

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

Логотип компании «Одноклассники»

Статья переведена благодаря спонсорской поддержке компании «Одноклассники».

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Rebecca Murphey
Автор:
Rebecca Murphey
GitHub:
rmurphey
Twitter:
@rmurphey
Сaйт:
http://rmurphey.com/
Email:
rmurphey@gmail.com
Наталья Фадеева
Переводчик:
Наталья Фадеева
вКонтакте:
natatik_l
Twitter:
@very_busy_girl
GitHub:
NatalieF

Комментарии (47 комментариев, если быть точным)

Автар пользователя
softshape

Насчет разработки под Windows товарисч просто не имеет достаточного опыта. FAR Manager, например, закрывает половину из перечисленных им задач, а для другой половины предоставляет командную строку автоматически.

Автар пользователя
iamstarkov

товарисч

ват? это девушка и уже не 2005

К сути: как вы используете FAR под виндой? и как он покрывает нужды git?

А я наоборот соглашусь с Ребеккой; из моего опыта Windows самая болезненная ОС для веб-разработчика из тройки самых популярных

Автар пользователя
softshape

Товарисч может быть и женского роду :)

FAR используем на 100%, но не для Git, там все делается через SmartGit, весьма удобную и продуманную оболочку. А так комбинация user menu в FAR'е, его встроенных возможностей, редактора с синтаксической подсветкой, некоторых плагинов, SSH, SCP и т.п. дают возможность все что нужно автоматизировать.

Автар пользователя
roose

@matmuchrapna вот какие проблемы с Windows? список пожалуйста!)

Автар пользователя
iamstarkov

Товарисч может быть и женского роду :)

@kizu на вас нет

Автар пользователя
iamstarkov

@matmuchrapna вот какие проблемы с Windows? список пожалуйста!)

помилуйте, я не просто так уже несколько лет пользуюсь OS X. Описал свой опыт windows-периода.

Автар пользователя
roose

@matmuchrapna так вот я и хотел узнать, с какими проблемами сталкиваются те, которые говорят что на Windows труднее.

Автар пользователя
iamstarkov

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

В любом случае я бы меня спросили какую ОС использовать для веб-разработки, я бы предложил OS X. На этот счёт показательно, количество скриншотов на винде http://shuvalov-anton.github.io/code-screenshots/

Автар пользователя
LostSenSS

Статья была написана 3 года назад. Интересно, что ничего с тех пор не поменялось.

На тему Windows для веб-разработки многое сказано в комментариях к оригинальной статье.

Автар пользователя
rinatoptimus

W3school назвали коммерческой чумой. 1) почему? 2) стоит ли учиться по этому ресурсу, ведь статья написана несколько лет назад, возможно, что-то уже изменилось на этом сайте?

Автар пользователя
sadcitizen

@matmuchrapna, я работаю под windows и у меня не возникает никаких проблем.

Автар пользователя
iamstarkov

@rinatoptimus 1) вот почему http://www.w3fools.com/ 2) какой ресурс вы подразумеваете в вопросе? Если «стоит ли учиться по w3schools?» то нет, не стоит. Если «стоит ли учиться по frontender.info?» то определённо да.

Автар пользователя
iamstarkov

@instanceofpro это аргумент из серии «у меня такая же нога и не болит»

Автар пользователя
ows-nightwolf

По поводу Windows - пользуюсь шелом babun (основан на Cygwin). Не сказать чтоб супермега, скорее костылище, но по крайней мере позволяет использовать ShellScript, и дает пользоваться конcолью как в Linux. А на вопрос "Чем плоха винда?" могу ответить - тем что мелкомягкие все очень усложняют. Например, вы знали что символическую ссылку в винде (разумеется, на ФС которые их поддерживают) не может создать пользователь входящий в группу "администратор"? Сам администратор - может, пользователи other тоже могут (после выставления соответствующих привелегий), а я, входящий в группу администраторы - не могу. В смысле вобще. Никак. На своем компе, на своей системе не могу сделать то что мне нужно. Спасибо мелкомягкие. И так на каждом шагу - то тут то там надо искать обходные пути. Я не думаю что в линуксе есть функционал который нельзя реализовать на винде, но резюмируя всю свою писанину могу сказать так: линукс создан чтобы решать проблемы, а винда - чтобы их создавать.

Автар пользователя
szarouski

@matmuchrapna, это не серьезно. Во всем можно достичь мастерства, и я уверен что примерно одной и той же ценой. С тем что ты упоменул выше (за исключением "и так далее") в windows уже проблем нет. Это из серии споров о том что лучше coffeeScript или javascript, angular или ember, php или ruby, mercurial или git, ... Умный человек понимает что если разобраться как инструмент работает, то в ногу он не выстрелит. У каждого свой путь в обучении.

Автар пользователя
softshape

@matmuchrapna, давайте меряться предметно. вот например одна из рутинных задач - у вас в репозитории лежит файл с шаблоном и у вашего коллеги (доступен по локальной сети) лежит такой же файл. Нужно найти различия между ними, т.е. запустить diff. Сколько времени у вас уйдет от начала действий до запуска? У меня ушло 14 секунд.

Автар пользователя
iamstarkov

это не серьезно.

что именно? мнение не серьёзно? я ни на что не претендовал, только поделился своими мыслями

Во всем можно достичь мастерства, и я уверен что примерно одной и той же ценой.

может быть. у меня другая точка зрения

С тем что ты упоменул выше (за исключением "и так далее") в windows уже проблем нет.

я искренне рад

Автар пользователя
iamstarkov

@softshape а давайте не мериться? потому что как минимум у меня не стояло никогда такой и даже похожей задачи (или я вас не понял)

Автар пользователя
iamstarkov

терминал-калека,

в windows уже проблем нет

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

Автар пользователя
softshape

@matmuchrapna, я уже выше писал про FAR Manager с его прекрасной поддержкой командной строки. Видимо, надо будет для Frontender'а отдельную статью написать про тулзы разработчика под Windows, чтобы не возникало холиваров на пустом месте.

Автар пользователя
iamstarkov

@softshape не все пользуются FAR, как по мне он страшный

Автар пользователя
iamstarkov

@softshape если не шутишь про статью, то это круто — напиши мне в личку, давай обсудим =)

Автар пользователя
softshape

@matmuchrapna, любой набор инструментов (включая описанный автором оригинальной статьи) будет субъективным по определению. и всегда найдется кто-то, кто скажет "а у вас {имя программы} страшная какая-то". но набор помогает быстро и удобно решать рутинные задачи разработчика, и самим своим существованием спорит с жалостью автора к разработчикам под Windows. не надо нас жалеть. а насчет FAR.... я пользуюсь им много лет и страшным он мне не кажется.

Автар пользователя
iamstarkov

напиши мне на почту про статью =)

Автар пользователя
ReklatsMasters

В windows конечно существуют проблемы, которые слегка осложняют процесс разработки но они не критичны. Полноценной альтернативы Total Commander нет ни в одной другой OS, плагины + настраваемый тулбар решает проблемы. Да и в консоли windows самое неудобное ограничение это невозможность построчного копирования. При этом вполне возможно поставить альтернативную консоль, например ConEmu. Для разработки на php можно поставить open-server, который всю чёрную работу делает сам. Всё, что мешает лично мне - невозможность из консоли обновить node (iojs).

Автар пользователя
szarouski

@matmuchrapna:

что именно? мнение не серьёзно?

не мнение, а вот это

@instanceofpro это аргумент из серии «у меня такая же нога и не болит»

.

последнее из значимых изменений в системный терминал это добавленная в win10 возможность копировать/вставлять

вы удивитесь но ещё наверное c xp копировать и вставлять можно было примерно так же как и в linux, главное в настройки зайти

@ReklatsMasters:

Всё, что мешает лично мне - невозможность из консоли обновить node (iojs).

не смотрели в сторону https://github.com/hakobera/nvmw?

Автар пользователя
iamstarkov

из моего опыта Windows самая болезненная ОС для веб-разработчика из тройки самых популярных

@matmuchrapna, я работаю под windows и у меня не возникает никаких проблем.

@instanceofpro это аргумент из серии «у меня такая же нога и не болит»

— я указал на слабый аргумент, в чём тут проблема?

вы удивитесь но ещё наверное c xp копировать и вставлять можно было примерно так же как и в linux, главное в настройки зайти

— не удивлюсь, так и делал. Но это согласитесь не очень удобно. И тут больше идея в том, что если нормальный копипаст в терминал добавляют спустя больше 20 лет после создания ОС, то всё таки что-то не так

Автар пользователя
roose

Люди, не надо холиваров =) каждый пользуется тем к чему привык, и уж 100% @matmuchrapna не перейдет назад на Windows :smile:, остаемся при своих.

Автар пользователя
andrew--r

Спасибо за перевод! Кстати, недавно вышла обновленная версия этой статьи:

A Baseline for Front-End [JS] Developers: 2015

Автар пользователя
SilentImp

А это уже весьма интересно, спасибо! Возможно возьмем на перевод.

Автар пользователя
skip405

Поправьте плиз глаголы в статье, раз девушка написала. "На днях я подготовил" на "На днях я подготовила" и тд.

Автар пользователя
iamstarkov

Поправил в ad6dd09

Автар пользователя
iamstarkov

котаны, а помогите, пожалуйста, в соседней статье разработчику на винде, у него грант ставится, но не может найтись виндой https://github.com/FrontenderMagazine/grunt-is-not-weird-and-hard/issues/2#issuecomment-100076081

Автар пользователя
KarelWintersky

Вроде бы проблема с путями решилась.

Ответ простой: на каждый чих Открой/закрой Свой терминал Герой!

Автар пользователя
digitalhitler

Вот так ого-го в комментах! В жизни бы не подумал, что в 2016-м году прочитаю холивар на тему «POSIX/UNIX/все дела vs Far Manager». Да что уж там, не в годе даже дело. Far Manager — это что-то со школьных времен, кажется.

Винда для веб-разработки неприемлима, это всем известно уже лет десять, но и странного в её популярности ничего нет: всем нам свойственно зачастую не искать лёгких путей. Ну и там всякие вещи вроде дела привычки. Однако, было бы нечестно умолчать об одном забавном наблюдении (думаю, не только моим): то что делает Майкрософт в последние годы — очень и очень хорошо. Десятой виндой даже не противно пользоваться! Плюс ну там всякие Visual Studio Code, IIS с удобной платформой веб-приложений.

Автар пользователя
iamstarkov

А тут ещё и убунтовский баш добавили в терминал

Автар пользователя
rantiev

Если у кого-то не возникает проблем на Windows, вы либо просто версткой или работаете в excel и калькуляторе или пасьянс раскладываете, тогда да чему там не работать (хотя и там есть), либо вам очень и очень везет.

Как один из минусов, при поиске любой документации по установке или установке программы. Скорее всего будет unix пакет поддерживаемый, но очень вероятно что от оригинального разработчика не будет поддержки windows (redis к примеру). В любой доке сначала идет про unix потом windows и там всегда написано про какие-то проблемы.

Если вы работаете много с node у вас 100% будут ошибки компиляции каких-то нод модулей.

Ну и можно продолжить другими вещами.

Автар пользователя
roose

@rantiev статья как бы про фронтенд, проблемы минимальные, если вы работаете со специфичным софтом который 100% не работает на винде, зачем вам винда? Просто надо правильно выбирать рабочее окружение.

Автар пользователя
rantiev

Статья то про фронтенд, но вы ведь вроде читали комментарии да? Даже минимальные проблему могут накапливаться, если можно без проблем, тогда зачем минимальные? Люди пишут что винда с фарманагером решит все проблемы ) ,а вложенных комментов здесь наверное нету поэтому может показаться что я про статью.

Автар пользователя
roose

@rantiev как я выше уже писал, каждый останется при своем, мне для верстки хватает винды, а мучаться с линуксом нет желания(не раз пробовал уже) git, nodejs, python пашут, мне достаточно. Есть GnuWin32, есть Chocolatey etc.

Автар пользователя
KarelWintersky

Если посмотреть на вещи оптимистически, ноутбуки MacBook Air не очень дорогие, мощные и на удивление портативные, кроме того существуют Ubuntu или Unix.

"не очень дорогие" заставляет грустно улыбнуться. Может быть для суперпрофи MacBook Air действительно "не очень дорогой", но обычному разработчику 13" "сверхтонкий ноут" обойдется всего в 90 тыс. рублей. Какие-то "несчастные" полторы тыщи баксов. Не очень дорогие, ага!

Автар пользователя
rantiev

Air не стоит 1500$, за 1500 люди покупают уже про 13". Даже за 1350$ Так что они действительно не очень дорогие. (хотя в этом году подороже чем в том уже) Если вы смотрите в первом попавшемся магазине, то возможно и за 2000 его вам продадут. Можно купить mac mini, штука хорошая и он уж точно не очень дорогой.

Автар пользователя
digitalhitler

Вот и настал мой чёрный день календаря: залил вином свою лошадку MBP 15" Late 2009, да так что насмерть. Пришлось пересесть на Acer с Windows 10 и... Вынужден признать, что, во-первых, человек привыкает к чему угодно, во-вторых - Windows 10 намного, прям намноооого лучше своих предшественниц. Тем не менее, у меня под столом крутится старый сервант с CentOS, ибо те же пакеты NPM у меня в Винде постоянно оборачиваются какой-то ректальной болью.

Теперь про ценообразование макбуков и лайфхаки. Свой ноут я купил пару лет назад "с рук". Модель - Apple MacBook Pro A1286 Core 2 Duo 2.66 Ghz 4 GB RAM SSD 80 GB & HDD 1 TB. За все это я отдал 25 тыс. руб. При этом, новые-клёвые ретины меньше сотки сейчас за примерно такую же конфигурацию не найти. Ещё я добавил оперативки 8 Гб (поставил 4+4) и, как мне казалось, не планировал бы менять машину ещё долгие годы: серверный SSD Intel + 8 GB RAM делают своё дело и будут делать ещё долго.

На днях, после залива ноута, процедуру (покупки) повторил и за 39 000 получил: MBP 15 Core i7 8 GB RAM 120 SSD 500 HDD, добавил памяти до 16 Gb (она вообще недорогая) и больше не пью в радиусе метра от компа. А SSD со старого ноута вселил жизнь и шустроту в тело моего PC-ноута Acer.

Я это всё к чему: если из*ебнуться, то можно нехило сэкономить. Я, конечно, понимаю, что у б/у железа есть всякие там особые подводные камни, но большая часть из них решается внимательностью.

Автар пользователя
KarelWintersky

я смотрел цены на яндекс-маркете. И на сайте эппла. И там, и там с ценами всё... нехорошо.

Автар пользователя
rantiev

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

Автар пользователя
KarelWintersky

Нет, зачем? У меня thinkpad 2007 года. Мне хватает :) я, правда, виндузятник по ряду причин, но линух на нём будет наверняка быстрее семерки. Ну и да, это комп для разработке "в поле", комп то с собой не возьмешь)

Автар пользователя
jemsgit

https://telegram.me/front_end_dev полезный канал для разработчиков