Веб-разработка *

Доброго всем дня, вечера, здравствуйте, коллеги.

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

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

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

Для затравки начнем с простого.

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

Я часто читаю тут истории о том, как люди становились тру программистами. Как в 13 лет они взламывали школьные сервера и придумывали хитроумные вирусы. Я завидую этим людям и их складу ума. Моё знакомство с программированием случилось в основной школе, когда я рисовал кружочки и квадратики в QBasic. Я обожал команду GOTO и совершенно не понимал Pascal. С тех пор утекло много времени, я выучил много новых терминов и зарабатываю на жизнь веб-разработкой. Но иногда мне кажется, что это всё те же кружочки с квадратиками, просто они свистят и забавно попёрдывают. А Pascal я так и не выучил.

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

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

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

Автор: Джоэль Спольски. Оригинал.

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

Файлы здесь.

Автор: Эндже Альбертини (Ange Albertini)
Перевод на русский: Lyr1k

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

Привет! Совсем недавно разбирался на даче и нашел пару тетрадей, блокнотиков и листочков с приветом из славных 90-х. Перенесемся на время в 96 год. Итак, я школьник, учусь в 8-ом классе. Дома гордо красуется ПЭВМ «Поиск». После работы он аккуратно накрывается тряпочкой. Там MS-DOS 5.0 на дискетке вместе с debug.exe. Позднее появляются Norton Utilites с красивым интерфейсом, Norton Commander. Ну, игрушки конечно тоже есть.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

Предыстория

Четыре дня назад Теренс Эден (Terence Eden) указал на несоответствие существующих HTTP кодов чудному новому миру, в котором мы теперь живём. Поводом послужило недавнее требование к провайдерам цензурировать доступ к The Pirate Bay: ведь неизвестно что должен вернуть сервер в ответ на запрос запретного документа. В процессе обсуждения Тим Брэй (Tim Bray) из гугла предложил ввести новый код статуса — 451.

Привет, Хабралюди!

У меня есть хобби. Я ночами (в нерабочее время) пишу библиотеку укладки графов: vivagraph.js. Хотел поделиться с вами, узнать что думаете. Визуализировал я сеть друзей своих на «В Контакте» с использованием WebGL. Но лучше один раз увидеть, чем читать, верно?



Это мои друзья. Каждая точка — человек, целый мир, с которым так или иначе мне повезло встретиться. Линия между точками обозначает дружбу. По этой сети можно, правда, сказать многое о человеке.

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

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

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

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

Всегда хотели найти более простой способ для работы с git и github на своей windows машине? Боялись командной строки и генерации ssh ключей через putty? Хотите присоединиться к огромнейшему сообществу разработчиков в мире?

Сегодня github анонсировал свой клиент для Windows, который можно использовать прямо из коробки.

Клиент написан на C#, работает на Windows XP, Vista, 7 и пре-релизе Windows 8. Прямо в установку включена инсталляция msysGit (git для win машин). Вливайтесь!

Я постараюсь сделать самое полное и подробное описание возможностей Web Inspector, на русском языке.
В первой серии мы залезем в настройки, посмотрим, что умеет консоль и поиграемся с панелью «Elements».

Так как Web-Inspector не переведен на Русский, я буду сохранять оригинальные названия.


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

От переводчика

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.

Продолжая тему предыдущего поста, прокомментирую слова tushev:

А еще интерфейс в старинной OS/2 требовал на порядки меньше ресурсов CPU и памяти.

Да, это действительно так – на порядки.

У меня нет универсального решения, и конечно я понимаю, что есть реальность, данная нам сегодня в ощущениях (исторические наслоения в виде HTML и CSS всех версий, HTTP). И очень тяжело что-либо изменить глобально. Но я хочу, чтобы каждый разработчик задумался над абсурдностью современного состояния дел в web-технологии. Иначе кардинального решения не будет ни у кого и никогда. Поэтому приведу факты, наводящие на размышления.

Пример UI 20-летней давности, который я предлагаю сначала воспроизвести всем апологетам HTML и CSS на этих языках, прежде чем минусовать «карму»: