Тематику cisco на хабре нельзя назвать популярной, зачастую интересные статьи остаются почти незамеченными. Но нас приятно удивил ажиотаж вокруг нашей предыдущей публикации. Больше тысячи человек добавили её в избранное, и это определённо говорит о том, что продолжение необходимо.
Кроме того, много людей, имеющих опыт реального планирования и строительства сетей, делали очень правильные замечания по резервированию. Дело в том, что предложенная в прошлый раз схема сети — это макет, лаборатория, на который мы будем отрабатывать и понимать технологии, поэтому такими вещами мы не озадачивались. В реальной же жизни, особенно, если вы оператор связи/провайдер, необходимы различные схемы резервирования: VRRP, STP, Link Aggregation, протоколы динамической маршрутизации.
Все замечания мы постараемся учесть и в конце цикла, вероятно, рассмотрим то, как сеть должна строиться, чтобы через полгода после запуска инженеру не было мучительно больно.

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

Под катом то же в текстовой и чуть более подробной форме.
Итак, вот они приехали — заветные коробки с надписью Cisco на борту.

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

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Не хватит пальцев на руках (да и на ногах), чтобы пересчитать все фантастические книги, фильмы и игры, где фигурирует энергетическое оружие. Признайтесь, каждому из вас хотелось заиметь подобную штуку, чтобы со зловещим хохотом поджаривать врагов многометровыми искусственными молниями. Товарищ с ником Rob не стал исключением, и под впечатлением от комикса The Five Fists of Science собрал свою собственную Тесла-пушку.

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

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

Если бы я не прочел её и не влюбился в идею Метавселенной, если бы она не заставила меня представить, насколько распределенная 3D сеть близка к воплощению в жизнь, если бы я не подумал я могу сделать это и, что более важно, я хочу сделать это, я бы никогда не встал на путь, который в конечном счете привел меня в Valve.

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.

Вступление.

Прежде всего стоит сказать, что такое Код Хэмминга и для чего он, собственно, нужен. На Википедии даётся следующее определение:

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

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта). Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Надоело отправлять пользователям подтверждения аккаунта и сброса пароля по утере на почту?
Пользователи уходят, устав заполнять вашу форму регистрации?
Вы точно уверены, что у посетителей вашего сайта есть аккаунт на Facebook или Вконтакте?
Не хотите хранить никакие персональные данные?
Ваши пользователи устали вводить логин и пароль?
Вашим пользователям лень даже нажать на кнопку «Войти»?
Видели, как это сделано на stackoverflow и хотите так же, и даже лучше?

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

В предыдущей статье про оформление изображений была затронута тема создания у картинок идеально закругленных углов, строгих теней и других графических «фишек» с помощью свойств box-shadow, border-radius и transition. Т.к. эти свойства обрабатываются некоторыми браузерами некорректно, проблема кроссбраузерности была решена обёртыванием изображения в контейнер, где оно (изображение) используется в качестве фона.

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

К счастью, обходной путь был успешно найден. О нем и будет рассказано в статье.

Статьи про создание tooltips'ов уже не раз поднимались на хабре [1,2] в виду большой популярности этого элемента. Сегодня вы узнаете еще один способ как создать простые, анимированные подсказки с помощью псевдо-элементов before и after, а так же свойства transitions.



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

Хотелось бы поддержать традицию совместного решения интересных задач и предложить одно из моих любимых заданий.

UPD_4. Известное мне решение найдено wirzus, лучшее на данный момент решение найдено коллективным разумом :) Отдельное спасибо Laplace и Lockal.


Прорыт канал, который дважды изгибается под углом 90 градусов. Ширина каждого участка канала 1 метр.
Очевидно, по каналу может проплыть плот размером 1 на 1 метр (трением о стенки можно пренебречь). Задача рассматривается на плоскости.
Требуется найти фигуру большей площади, которая также сможет преодолеть канал.
Предлагаю писать свои варианты решения, в которых площадь больше 1 м² или, соответственно, предыдущего лучшего решения. Когда найдёте известное мне решение, я напишу.
Готов ответить на ваши вопросы в комментариях.
Удачи!

Здравствуйте!

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

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

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

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

Признайтесь себе, только не лукавьте: бывали ли у вас случаи, когда какой-нибудь «лохоманагер» со школьной скамьи пренебрежительно отзывался о вас как о скованном, нелюдимом человеке или «умнике» себе на уме? Да кто он такой? Что он может — только языком молоть… Стоп!

Привет!

С начала этого года в России вступил в силу страшный закон, отменяющий ЕСН, и сразу же по интернету начали гулять мифы о том, какие нововведения ждут предпринимателей – на форумах пишут о дополнительном налоге в 14%, новой отчетности и прочих дьявольских хитростях. При этом опытные бухгалтеры многозначительно покряхтывают, говорят «Боже мой, как же все поменялось» и задумчиво качают головой.

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

В основном все осталось как и прежде. Поменялись всего 3 вещи:

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

Да, это он в 1998 году продал свою компанию Viaweb интернет-гиганту Yahoo, которая впоследствии назвала этот продукт Yahoo Store. Да, это он основал венчурный фонд Y Combinator. Да, это его журнал BusinessWeek включил в список 25 наиболее влиятельных людей в Сети за 2008.

Хотите читать по-настоящему интересные аналитические статьи? Вам однозначно к Полу. Я настоятельно рекомендую прочитать его заметки. Особенно если вы it-шник. Особенно если вы собираетесь открывать свой бизнес.

От переводчика
Это вторая часть повествования Rico Mariani. Начало было здесь и здесь.

Visual C++ 2.0 (кодовое имя Dolphin, Дельфин) был очень амбициозным проектом. Мы были счастливы выпустить Visual C++ 1.0, но там было несколько моментов, которые абсолютно нас не устраивали. Одним из них — наиболее, пожалуй, важным — было то, что работа с окнами являлась сущим кошмаром. Visual C++ 1.0 использовала стандартный многооконный MDI-интерфейс для всех окон, включая такие вещи, как окно регистров, окно отслеживания значений, окно вывода и т.д. В итоге эти ключевые инструменты просто тонули в потоке окон, открытых редактором и отладчиком. Это все было очень неприятно.

Единой «Истории возникновения Visual Studio» нет и быть не может: у каждого человека, вовлеченного в ее создание, есть своя версия. Если приспособить известную цитату, то «В Обнаженном Городе ходит множество историй...».

От переводчика
Продолжение Части 0,5

Как выясняется, C++ — язык довольно сложный для компиляции; да что там — он сложный даже для понимания. Я помню одну беседу о том, какими запутанными могут быть указатели на члены класса. Итоги были потрясающими и сводились к тому, что указатели могут указывать на члены, определенные в виртуальном базовом классе. В этом весь C++: отдельные вещи кажутся простыми, но как только вы начинаете их комбинировать с другими — дело сразу усложняется.

Я решил провести один эксперимент, суть его пока не могу разглашать, но по результатам обязательно опишу его))) Для этого эксперимента, мне нужно написать приложение которое работает как сервис в Windows.

Этот вопрос входит, наверное, в ТОП10 вопросов на форумах :) Скорей всего это требование дизайнера или заказчика.

Итак, решение, на первый взгляд, простое:

<a href="#" onclick="document.getElementById('myform').submit(); return false;">Отправить</a>

Но тут же возникает (как ни странно :) следующий вопрос это, а если JS будет у посетителя отключен?

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

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