30 цитат великих программистов. Цитаты айтишников

Цитаты великих айтишников | AppTractor

Существуют невидимые чернила, — прошептала она и, трижды коснувшись палочкой дневника, произнесла: — Апарекиум!

Мы дизайнеры и мы волшебники. Что-то для нас кажется обычным и привычным, но, к сожалению, мы работаем с простыми магглами. Всю нашу работу мы должны делать максимально прозрачно, чтобы нашим коллегам не пришлось использовать заклинание Апарекиум в поисках того, что мы написали невидимыми чернилами.

1. Много разных диагоналей, что делать

Если вы веб-дизайнер, но никогда не работали с мобильными приложениями, то скорее всего у вас возникнет вопрос про большое количество экранов мобильных устройств. А еще у них разные пропорции и на разных платформах разные стандарты экранов. О ужас! – скажете вы. Но все достаточно просто. Существуют основные разрешения девайсов под которые нужно рисовать дизайн. На iOS это 375х667, а на Android 360х640. Это основные пропорции, которые используются практически на всех девайсах. В большинстве случаев остальные смартфоны увеличиваются в высоту, а это не доставляет особых проблем, просто у вас будет видно чуть больше контента. В некоторых случаях стоит учитывать смартфоны с меньшим разрешением или другими пропорциями, например iPhone 4. Для него может потребоваться отрисовать отдельные версии экранов, если контент не помещается на экран.

2. Негативные кейсы

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

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

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

3. Активная клавиатура

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

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

4. Карта экранов

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

Карта навигации составляется как на все приложение, так и на отдельные блоки, которые потом будут встраиваться в приложение. Карту можно составить и на этапе проектирования/прототипирования приложения, когда уже будет понятна основная логика работы приложения. Но по своему опыту для выстраивания логики приложения и составляется карта переходов. Она позволяет выявить недостающие экраны, о которых вы могли забыть.

Карту переходов можно составлять в таких программах: Realtimeboard, Axure, Figma, Sketch. Но для меня самым удобным вариантом оказался Overflow.

5. Текст в контейнере

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

6. Нет указания типа навигации

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

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

7. Удобный экспорт

Вы нарисовали макет, утвердили его у заказчика, выложили все макеты для верстки и вроде выдохнули. Но вот откуда ни возьмись прибегает разработчик и говорит вам о том, что иконка выгружается коряво. о_О

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

8. Не всегда то, что нарисовано легко реализуемо

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

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

9. 50 оттенков серого

Если у вас большой макет сайта или приложения и цвет используется 2-3 раза на разных элементах, то уверенно создавайте стиль. Стили ускорят не только вашу работу и не дадут применить к элементу похожий, но не идентичный цвет. Но и разработчику будет потом намного проще, т.к. стили можно выгрузить в Zeplin. Главное не забывать о том, что при индивидуальном изменении элемента с привязанным стилем есть возможность того, что вы случайно можете изменить стиль. Лучше заранее отвязать от стиля элемент и редактировать его под свои нужды.

10. Кратности в макетах

Говорить на тему сеток можно бесконечно. Но в данном контексте хочется рассказать о личном опыте построения интерфейса. Недавно читал пост в facebook и там разгорелась очень интересная дискуссия. Кто-то настаивал на том, что все интерфейсы должны быть построены по определенному формату, т.е. никакой индивидуальности. И тут же спрашивают о том, что делать если экран имеет нечетные параметры? Например iPhone 8 имеет разрешение 375х667, что же делать в таком случае? Если отталкиваться от построения на четных количествах столбцов, то здесь едет вся логика. Google же предлагает использовать сетку основанную на 8 единицах.

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

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

11. Нестандартный кернинг

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

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

Есть очень интересная игра, в которой вы можете потренироваться: https://type.method.ac

12. Своевременная актуализация

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

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

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

Из этого всего следует то, что нужно стараться помнить о том, что дизайн должен быть отрисован под несколько платформ. Завести такое правило в компании или у себя в голове. Даже если менеджер не поставил задачу, а в компании действует правило: “если нет задачи в таск трекере, то и нет ее результата”, то можно перенести дизайн на другие платформы и спокойно ждать пока разработчику он понадобится. И еще вдобавок можно тонко намекнуть, кто не поставил задачу :)

13. Тени картинками

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

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

Хотелось донести до вас, что упрощая работу себе, вы упрощаете ее и другим. Старайтесь делать все максимально четко и понятно. Объясняйте магглам простые дизайнерские истины, ведь они не волшебники.

Вкусного вам дизайна!

apptractor.ru

Лучшие IT-цитаты последних столетий - Актуальные новости сферы Информационных технологий на портале ITMozg

2013-12-26

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

О разработке

Есть два способа разработки программного обеспечения. Первый — сделать ПО настолько простым, чтобы в нём не было недостатков. Второй — сделать его настолько сложным, чтобы в нём не было очевидных недостатков. (C.A.R. Hoare)

Учитывая печальное состояние современных компьютерных программ, разработку ПО до сих пор можно считать искусством, а не научной дисциплиной. (Bill Clinton)

Два самых известных продукта, созданных в Университете Беркли — это UNIX и LSD. Это не может быть просто совпадением. (Jeremy S. Anderson)

Самое потрясающее достижение программного обеспечения состоит в том, что оно способно уничтожить стабильность и любые достижения аппаратного обеспечения. (Henry Petroski)

Те, кого беспокоит бесплатное ПО, обычно производят продукты, которые стоят и того меньше. (David Emery)

Поставщики ПО постоянно пытаются сделать свои продукты более user-friendly. Пока что все попытки это сделать сводятся к написанию слов user-friendly на обложке документации. (Bill Gates)

О программистах

Программисты постоянно соревнуются со Вселенной: они пытаются создать всё более идиотоустойчивые программы, а Вселенная создаёт всё более совершенных идиотов. Пока что Вселенная побеждает. (Rich Cook)

Основная проблема программистов состоит в том, что их ошибки невозможно предугадать. (Seymour Cray)

Для начала изучите теорию. Затем обретите собственный стиль программирования. И, наконец, забудьте об этой ерунде и просто пишите код. (George Carrette)

Не переживайте, если что-то идёт не так. Если бы работало абсолютно всё, не работали бы вы. (Главный закон разработки ПО)

Образование в сфере компьютерных технологий точно так же не сделает из вас отличного программиста, как изучение кистей и красок не сделает вас прекрасным художником. (Eric Raymond)

Оценивать эффективность процесса программирования количеством написанных строк кода — то же самое, что оценивать процесс создания самолёта по его весу. (Bill Gates)

Итерация свойственна человеку, рекурсия божественна. (L. Peter Deutsch)

О языках программирования

Существует только два вида языков программирования: те, которые всех раздражают, и те, которые никто не использует. (Bjarne Stroustrup)

PHP — это малое зло, созданное дилетантами, а Perl — великое зло, созданное лучшими извращенцами в своей сфере. (Jon Ribbens)

COBOL наносит непоправимый вред работе мозга; именно поэтому его преподавание должно считаться уголовным преступлением. (E.W. Dijkstra)

В мире нет такого языка программирования, на котором разработчики не смогли бы написать плохую программу. (Larry Flon)

Создание языка программирования — это как прогулка по парку. По парку Юрского периода. (Larry Wall)

О сексе

Утверждать, что Java хорош тем, что работает на всех ОС, — то же самое, что утверждать, что анальный секс хорош тем, что подходит к любому полу. (Alanna)

Программирование — это как секс: одна ошибка, а последствия на всю жизнь. (Michael Sinz)

Программы — это как секс: гораздо лучше, когда бесплатно. (Linus Torvalds)

Об ошибках

Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения. (Edsger W. Dijkstra)

Есть два способа написать программу без ошибок; работает только третий. (Alan J. Perlis)

Если бы McDonalds разрабатывал ПО, один из сотни биг-маков был бы отравлен, а администрация отвечала бы: «В качестве извинения примите купон на два бесплатных биг-мака». (Mark Minasi)

Ошибки свойственны человеку, но для нечеловеческих ляпов нужен компьютер. (Paul Ehrlich)

Всегда пишите код так, как будто сопровождать его будет психопат, который знает, где вы живёте. (Martin Golding)

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

Четыре предсказания, которые не сбылись

Полагаю, мировому рынку хватит и пяти компьютеров. (Thomas J. Watson, председатель правления IBM, 1948 г.)

Ну и зачем нужна эта хреновина? (инженер отдела разработки усовершенствованных компьютерных систем IBM говорит о микропроцессоре, 1968 г.)

Нет никаких причин иметь компьютер в каждом доме. (Ken Olson, президент Digital Equipment Corporation, 1977 г.)

640 Кб должно хватить для любых задач. (Bill Gates, 1981 г.)

Подготовлено в предновогодней ажитации Люсей Ширшовой.

itmozg.ru

30 цитат великих программистов: fritzmorgen

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

1. Билл Гейтс. «Аккуратный программист — быстрый программист».

2. Стив Джобс. «Сегодня ты делаешь код, завтра код делает тебе деньги».

3. Маркус Перссон. «Если твой код работает, значит это хороший код».

4. Гейб Логан Ньюэлл. «Чтобы понять код мида, нужно быть мидом. Чтобы понять код сеньора, достаточно быть джуном».

5. Брайан Керниган. «У каждого языка есть время жизни. За исключением ’Кобола’, конечно».

6. Линус Торвальдс. «Настоящий программист гораздо больше читает, чем пишет».

7. Марк Цукерберг. «Комментарии в коде должны быть похожими на кружевные трусики: маленькими, прозрачными, и оставляющими достаточно места для воображения».

8. Павел Дуров. «Скорость имеет значение».

7. Расмус Лердорф. «Когда я не знаю, с чего начать, я открываю чистый файл и пишу: ’// С чего бы начать?’. Дальше всё идёт как-то само собой».

8. Ада Лавлейс. «Если ваша работа не документирована, значит вы не работали».

9. Дональд Эрвин Кнут. «Писать книги сложнее, чем писать программы. Любой писатель может стать хотя бы посредственным программистом. Обратное, к сожалению, неверно».

10. Бьёрн Страуструп. «Если над кодом работали 20 человек, значит его можно сделать в 20 раз меньше и в 20 раз быстрее».

11. Ричард Мэттью Столлман. «Если бы Омар Хайям жил сейчас, он наверняка был бы пиратом».

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

13. Сид Мейер. «Не ожидайте ухоженных ногтей от первопроходцев».

14. Алан Кёртис Кэй. «Можно сделать довольно большой проект, вообще не прикасаясь к мыши. Но зачем?».

15. Брэм Коэн. «На длинных дистанциях выигрывают стайеры».

16. Джон Кармак. «Всегда начинайте со структуры данных».

17. Джеймс Гослинг. «Кофе не помогает программировать, зато он приятен на вкус».

18. Андерс Хейлсберг. «Не бывает хороших языков, бывают хорошие программисты».

19. Кен Томпсон. «Проще отучить собаку лаять на почтальона, чем отучить админа работать под рутом».

20. Давид Хейнемейер Ханссон. «Когда-то я был достаточно наивен, надеясь, что мне достаточно будет хорошо выучить один язык».

21. Эндрю Таненбаум. «Завидую тестировщикам: все хотят с ними дружить».

22. Юкихиро Мацумото. «Отдавайте распоряжения в письменном виде: программист вы, в конце концов, или нет?».

23. Ларри Уолл. «И где теперь ваш ассемблер?».

24. Крис Хьюз. «Чем опытнее программист, тем лучше он осознаёт всю скудность своих знаний и навыков».

25. Эрик Стивен Рэймонд. «Хакер всегда выигрывает в честной схватке, потому что он нечестен».

26. Питер Нортон. «Идеальному коду место в музее: там ценят всякие древности».

27. Дастин Московиц. «Не экономьте на дизайне: конечный пользователь ровным счётом ничего не понимает в программировании».

28. Стив Возняк. «Довольно сложно руководить программистом, которому не нужны деньги».

29. Ричард Мэттью Столлман. «Выучите LISP, и вы не будете работать ни одного дня в своей жизни. Выучите PHP, и вы таки сумеете заработать себе на кусок хлеба».

30. Брендан Эйх. «Прежде, чем начать сеанс парного программирования, уберите из комнаты все острые предметы».

fritzmorgen.livejournal.com

Высказывания, выражения и поговорки айтишников

Все мы время от времени употребляем устоявшиеся выражения / высказывания в нашей среде. И нам стало интересно, а какие же выражения / высказывания популярны в IT сфере. И вот какой список у нас получился:

Для программистов

«Билд в студию»
«Это не баг, это фича»
«Сдал релиз иди в Ливиз» (примечание: выражение употребляется Питерскими программистами. Ливиз — местный ликеро водочный завод)
«Когда я вижу, как ты верстаешь, Малыш, ты меня пугаешь»
«Хорошо написанная программа — это программа, написанная 2 раза»
«Ничто так не ограничивает полет мысли начинающего программиста, как компилятор»
вариация на тему: «Ничто так не ограничивает полет мысли зрелого программиста, как Project Manager»
Хорошая жена может провожать мужа-программиста на работу словами «Чистого кода тебе!»
«Тяжела и неказиста жизнь без парня-программиста» (примечание: выражение должно употребляться девушками)
Ставшее теперь популярным выражения «писать говнокод» / вариация на тему: «Адовъ говнокод!» (источник перлов тут)
«Программисты — это устройства, преобразующие кофеин в код»
«Sex, drugs & rock'n'roll? — Bugs, hex & source control!» / вариация на тему: «Sex, drugs & rock'n'roll? — Sux, bugs & plug'n'play!»
«Улучшение работающего продукта приводит к его ухудшению»
«Хорошо задокументированный баг, автоматически становится фичей!»

Для тестировщиков

«Критичный баг, найденный тестировщиком в последний день, является багом в работе самого тестировщика» @Tanyapdr
«Если что-то может сломаться, оно должно сломаться именно сейчас»

Для админов

«Все пропатчить и проапдейтить»
«Быстро откаченное выложенным не считается»
«Семь бед — один reset»
«Не было печали — апдейтов накачали»
«Первый файл com’ом»
«Какой error не мечтает стать general’ом…»
«Не TCP мое IP»
«Format твою C:!»
«Как сервер назовешь, так он и будет работать»
«Первый тост за локалхост»
«Стабильного коннекта, Быстрого пинга!» @Лукьяненко, трилогия Лабиринт отражений
«Господь Бог — самый первый админ… Уж забанит так забанит!»
«Сервер — не суетись под клиентом!»
«Один сервер — хорошо, а два лучше»
«Знаю отличную шутку про UDP, но не факт, что она до вас дойдет» (разъяснение тут)

Для всех

«Не USB мне мозги»
По поводу windows: «it works but it isn't working»
«Как два байта переслать»
«Восстановление системы после критического сбоя» (примечание: про похмелье)
«А rar-чик просто открывался»
Из прошлого: «Типун тебе на модем»
Из прошлого: «Провайдер не лошадь, к утру повезет» (примечание: речь идет о том, что по модему приходилось дозваниваться часами)
«Ясна консоль» (примечание: смысл выражения — все предельно понятно)
«Глаза болят, а руки делают»
«Большой программе — большие глюки»
«Нас Reboot, а мы крепчаем»

Ссылки по теме:

www.it-dominanta.ru

Высказывания, выражения и поговорки айтишников

Все мы время от времени употребляем устоявшиеся выражения / высказывания в нашей среде. И мне стало интересно, а какие же выражения / высказывания популярны в IT сфере. С этим вопросом я обратился к моей аудитории портала МойКруг. И вот какую обратную связь я получил (предлагаю на этом не останавливаться и активно дополнять этот список):

Для программистов

«Билд в студию»

«Это не баг, это фича»

«Сдал релиз иди в Ливиз» (примечание: выражение употребляется Питерскими программистами. Ливиз — местный ликеро водочный завод)

«Когда я вижу, как ты верстаешь, Малыш, ты меня пугаешь»

«Хорошо написанная программа — это программа, написанная 2 раза»

«Ничто так не ограничивает полет мысли начинающего программиста, как компилятор» вариация на тему: «Ничто так не ограничивает полет мысли зрелого программиста, как Project Manager»

Жена может провожать программиста на работу словами «Чистого кода тебе!»

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

Ставшее теперь популярным выражения «писать говнокод»

«Программисты — это устройства, преобразующие кофеин в код»

«Sex, drugs & rock'n'roll? — Bugs, hex & source control!»

Для тестировщика

«Критичный баг, найденный тестировщиком в последний день, является багом в работе самого тестировщика» @Tanyapdr

«Если что-то может сломаться, оно должно сломаться именно сейчас»

Для админов

«Все пропатчить и проапдейтить»

«Быстро откаченное выложенным не считается»

«Семь бед — один reset»

«Не было печали — апдейтов накачали»

«Первый файл com’ом»

«Какой error не мечтает стать general’ом…»

Для всех

«Не USB мне мозги»

По поводу windows: «it works but it isn't working»

РезюмируяПредлагаю всем принять участие в пополнении коллекции интересных высказываний / выражений в IT сфере.

Ссылка по теме:50 цитат о программировании

Автор: Denrit