Не смотря на развитие, внедрение новых стандартов и плюшек в браузерах, у нет единых стандартов, как отображать элемент /> по умолчанию. Более того, у этого элемента нет атрибутов, позволяющих его в какой-то мере стилизовать.
Из-за необходимости привести это поле формы к единому виду во всех браузерах и «вписать» в разработанный дизайн, после поисков и анализа материалов в интернете был разработан метод замены вида поля формы на html+css, и js для расширения функциональности.

Как по умолчанию выглядит это поле?

Техника – это способ справиться с заданием, и у нас, разработчиков и дизайнеров фронтэнда, этих способов бывает достаточно много. При это, будучи погруженными в рутинную работу, мы порой не всегда замечаем как стремительно меняется окружающая нас сфера. В период с 2002 по 2010 годы сообщество фронтэнд-разработчиков буквально покрывалось язвами избыточного кода и ресурсов, от которых страдали и работа сайтов, и удобство их использования. Чтобы с этим справиться, мы придумали уйму хаков, трюков и уловок под кодовым названием «техника». Мы по-прежнему продолжаем выполнять поставленные перед нами задания, просто используем не самые эффективные способы.



Оборачиваясь назад, отметим, что в последние несколько лет установились новые, лучшие, стандарты и способы их применения, позволяя нам создавать более продвинутые «техники». Этот новый мир, открытый перед нами, называется «modern web». Web 2.0, которым восхищались в свое время, сегодня для нас стал запутанным и застойным. С одной стороны нет сомнений в том, что подобная судьба постигнет и то, что мы называем «modern web». С другой — пока что мы можем использовать этот термин и злоупотреблять им сколько угодно, пока понимаем, что он означает.



В 2010 появился стандарт HTML5, обеспечивающий совершенно новую, полустандартизованную веб-среду. Такие браузеры, как Opera, Firefox, Chrome и Safari приняли нововведения, и их разработчики вышли за пределы реализации стандартов и изучения интерфейса программирования приложений. Чтобы представить себе, насколько автономны эти браузеры, можно ознакомиться с отличной наглядной демонстрацией поддержки HTML5 на www.html5readiness.com.

Ситуация

В сети на сегодняшний день достаточно много описаний по развертыванию IP телефонии и в основном это два варианта:

• Берём готовый дистрибутив в виде установочного образа (Elastix,Trixbox etc...) и в результате получаем рабочий комплекс не имея никаких знаний в Linux
• Устанавливаем комплекс самостоятельно занимаясь при этом компиляцией из исходных кодов и ручной правкой множества конфигурационных файлов.

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

Предпосылки

В процессе внедрения IP телефонии в одной из компаний с разветвленной структурой филиалов рассматривались оба варианта но оба не устраивало по ряду причин:

• Бюджет на проект не подразумевал затрат на привлечение сторонних компаний для развертывания проекта, весь комплекс телефонии было решено развертывать своими силами.
• Большинство системных администраторов в филиалах были не знакомы с Linux системами и являлись чистыми Winows админами.
• Требовалось заложить высокую гибкость системы под будущие, еще не придуманные задачи.

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

Герхард Лауссер — эксперт в области nagios-совместимых систем мониторинга, автор множества публикаций, разработчик широко используемых плагинов для мониторинга многих коммерческих систем (один из них — check_hpasm, мы даже подробно разбирали ранее). Интервью выполнено сотрудником компании WürthPhoenix, которая занимается производством систем мониторинга в виде aplliance под торговой маркой NetEye и опубликовано в блоге компании^* в 2010 году. г-н Лауссер излагает взгляд на использование систем мониторинга для мониторинга масштаба предприятия.
_{*Это не реклама, изделия NetEye и продукция компании WürthPhoenix в РФ не поставляется.}

Решил написать, так как в основном есть статьи по резервированию основного 3g канала на другой, а 3g как резервный при проводном интернете — почему то сложно найти.

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

Покопав интернет, были найдены устройства с поддержкой 3g «свистков». Выбор был из Zyxel Keenetic, drytek и TP-Link (но всю жизнь работали с Asus и D-Link по объективным причинам и собственным статистическим данным). По опыту решения «всяких» задач, выбор пал на TP-Link. Выбрать было просто, Open WRT дружит со всеми TP-Link'ами (запасной вариант). Так же требования по 3g связи. Предоставили мне Huawei E367 от мегафона.

Коробка попала ко мне в руки. (описывать ее не буду, описаний много, сразу к делу). Приятные плюшки от TP-Link'а радовали всегда. В «поле» он у нас ни когда не тестился. Работа всегда велась с более стабильными роутерами. Но Open WRT в данном вопросе — перевесил все сомнения. И как оказалось — не зря, но об этом позже.

Базовая прошивка, базовая настройка, Wan preffered, запуск, тест. Эмуляция «сетевой кабель не подключен» работает на ура. В обе стороны как надо переключается канал. Но мы то знаем, что «падения» бывают не только на «крыше», но и дальше. Кто то что то копал, задел кабель, порвал. Свитч жив, линк по кабелю жив, роутер «думат» что всё ок. Нас это не устраивает.

Задача:
1) TP-LINK TL-MR3420 V2
2) 3g интернет Мегафон Huawei E367
3) Провайдер с настройками по Static IP и проводом с RJ-45

В своей компании для тех. поддержки клиентов используем чат+хелпдеск от kayako, но столкнулись с необходимостью найти отдельный сервис онлайн чата для новых проектов. По старой привычке — выбор делаем так: составляем список минимальных требований, потом находим все подходящие под них сервисы и проводим их тестирование, и уже из них выбираем лучший вариант.

Исходные требования:

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

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

Конец 2012 года прошел в суматохе, и каким-то образом я упустил из внимания две важные новости: в декабре вышел GitLab 4.0, а на середину ноября пришелся релиз GitLab Continuous Integration Server.

GitLab — это замечательное FOSS решение для хостинга git-репозиториев внутри закрытой инфраструктуры. Функционал во многом аналогичен GitHub, в частности доступны базовые возможности администрирования и разделения полномочий между пользователями, issue трекер, вики, code review и мердж реквесты (аналог пулл-реквестов на GitHub). И внеочередной плюс теперь, как по мне — это интеграция с GitLab CIS.

GitLab CIS — если GitLab послужит Вам заменой GitHub, то GitLab CIS призван стать заменой Travis CI. Набор фич соответствующий: запуск по git push, отдельные билды под бранч, интеграция с любыми git-репозиториями и бейджик со статусом текущего билда.

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

Что примечательно, работу ведут и курируют скромные украинские парни Дмитрий Запорожец и Валерий Сизов.

Приветствую! Надеюсь, эта статья будет кому-нибудь полезна.

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

Итак, кончаю муть, перехожу к «технической» и практической стороне дела.

Добрый день, уважаемые хабрапользователи.

С недавних пор я занимаюсь разработкой на Ext JS 4 и Zend framework 2.

Пользуясь случаем, хотелось бы создать небольшую серию статей, «на пальцах» освещаюшую некоторые основные компоненты Ext JS 4, без которых не обойдется ни одно приложение на Ext JS (простите, серия,- громко сказано,- пишу из песочницы).

Итак, Grid, часть 1.

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

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

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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



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

Приветствую, коллеги.

Пролог

Возникла у нас задача – сделать гостевой интернет. Т.е. гость приходит, подключается к сети (WiFi или кабель) и пытается выйти в Интернет. При попытке зайти на сайт у него «должно спросить пароль».
Надо отметить, подобные вопросы о решении такой задачи часто возникают на форумах. Есть куча платного софта (не рассматривался в принципе, ибо задача низкоприоритетная) и какие-то бесплатные решения. Поиск по форумам не дал определиться с выбором, посему было решено в свободные минуты сделать сие самостоятельно.

Основными требования:

Ресурсы на создание – как человеческие (рабочее время), так и материальные – минимальны.
Нагрузка – маленькая. Обычно такой системой будут пользоваться не более 10 человек в день.
Критичность доступности – низкая. Если система сломалась – то ремонтировать будут в последнюю очередь. Потеря нескольких пакетов – не принципиальна.
Изолированность – полная. Если сломают какие-либо части – локальная сеть не должна пострадать.
Платформонезависимость – клиентами будут всякие гаджеты – от телефона до большого компа.