Так уж сложилось, что Firefox использует однопроцессную модель, и реальность такова, что такой подход с учётом динамики развития сети и частичной связки с XUL вызывает, мягко говоря, много неудобств. Один процесс должен обрабатывать несколько потоков, что очень сильно сказывается на производительности браузера в целом. Отзывчивость Firefox оставляла желать лучшего, когда тот же Google Chrome прекрасно рендерил тяжёлые страницы, что никак не сказывалось на производительности других вкладок.

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

Время от времени случается, что ко мне обращаются пользователи с заглючившим Windows 7 или 8 (наверняка так же и с «десяткой» будут жертвы), у кого постоянно запускается «Восстановление системы» вместо нормальной загрузки, и автоматический механизм поиска и устранения проблем не справляется.



Мне удалось разобраться, почему возникает сообщение «Было предпринято несколько попыток, но причину проблемы определить не удалось» и как вернуть жизнь операционке без радикальной переустановки.

Если вы из тех, кто «работал ещё Там-То!» и «делал ещё То-То!», а сейчас счастливо отдыхаете на пенсии — эта статья не для вас. Просто спасибо за труд и примите мои поздравления. Но если же вы, как и я, даже став немного старше всё ещё ощущаете страсть к программированию, радуетесь виду кода и не можете устоять перед желанием написать ещё что-нибудь, тогда продолжайте читать.

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Приветствую вас, уважаемые пользователи «Мегамозга»!

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

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

Меня зовут Данилевский Кирилл и мне сейчас 36 лет. Я закончил Киевский политех в далеком 2000 году, и учился на факультете информатики. После выпуска начался мой самостоятельный полет разработчика.

Как веб-разработчик, я уже работаю более 10 лет. В юные годы (20-25 лет) я был полон оптимизма и всевозможных радужных идей. Я брался делать все. Все свои идеи я пытался реализовать самостоятельно.

C момента анонса проекта Хостинг Кафе прошло уже более двух месяцев и я бы хотел рассказать о том, что было сделано за это время:

• значительное увеличение базы хостеров
• запуск проекта LICENSE.menu — поисковик по лицензиям на панели управления, биллинги и т. д.
• запуск англоязычных проектов VDS.click и SHARED.click
• возможность поиска хостера по языку сайта и языку, на котором разговаривают сотрудники компании
• борьба с хостерами, которые не используют SSL в биллинге

Как бывало здорово, берешь образ CentOS 6.x, выдергиваешь из него куски, и пихаешь все это на USB флешку, по соседству с другими системами.

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

У меня появился Linux на домашнем компьютере, и я поспешил обжиться в новой ОС. Она была установлена с systemd init process. Это было мое первое знакомство с этим новым инструментом. Cвой ноутбук я использую для каждодневной жизни и для программирования. Мне хотелось включать рабочие программы (Apache2 и MySQL) только на время, пока я их использую, чтобы не тратить впустую ресурсы своего компьютера. Дополнительно, для тестирования я написал bash скрипт, который выгружает содержимое одной из MySQL БД c жесткого диска в ОЗУ (в tmpfs) – так тесты выполняются значительно быстрее. По идее, я мог бы начинать свой рабочий день вот так:

systemctl start apache2.service
systemctl start mysqld.service
/root/scripts/mysqld-tmpfs start

И заканчивать его:

systemctl stop apache2.service
systemctl stop mysqld.service
/root/scripts/mysqld-tmpfs stop

Но мне хотелось сделать вещи “как надо”.

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

CSS Protips

Это современные решения типичных проблем, коллекция советов, которая поможет вам улучшить ваши профессиональные навыки CSS.

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

Приветствую, для вас подготовлен еще один перевод заметок на тему CSS. Мэтт Смит, разработчик из Портленда, поделился CSS-советами и выложил их на GitHub. Мне особенно понравилась его подборка, она структурирована, не особо громоздкая в плане скучных больших текстов и описаний, и в целом будет понятна даже новичку. Я буду рад, если в комментариях мы с вами обсудим каждый пункт и в итоге дадим некоторые заключения. Итак, приступим.

Cодержание

1. Используем псевдо-класс :not для задания рамки навигации
2. Добавляем межстрочный интервал элементу body
3. Центрируем по вертикали все что угодно
4. Правильно разделяем запятыми элементы списков
5. Отрицательный порядковый номер в nth-child
6. Используем SVG-логотипы
7. Аксиоматический CSS
8. Максимальная высота у CSS-слайдера
9. Наследуем box-sizing
10. Одинаковая ширина ячейки таблицы
11. Динамические внешние отступы при помощи flexbox
12. Используем селектор атрибутов пустых ссылок
13. Стили по умолчанию для обычных ссылок

Я провел более пяти лет в роли разработчика системы биткоин. Миллионы пользователей и сотни разработчиков использовали мои программы, а мои лекции привели к созданию нескольких стартапов. Я рассказывал про биткоин на Sky TV и BBC News. Меня цитировали в Economist в качестве эксперта по биткоинам и известного разработчика. Я объяснял эту тему для SEC, банкирам и обычным людям в кафе.

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

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

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

Подумайте об этом. Если бы вы никогда не слышали про биткоин раньше, понравилась ли бы вам сеть платежей, которая:

• не может передавать существующие у вас средства
• имеет непредсказуемые комиссии за переводы, которые быстро растут
• позволяет покупателям отменять платежи после выхода из магазина простым нажатием кнопки (если вы не в курсе этой «возможности» – это потому, что биткоин её только что ввела)
• страдает невыполненными и нестабильными платежами
• контролируется Китаем
• в которой компании и люди, участвующие в её развитии, находятся в фазе гражданской войны

Рискну предположить, что ответ будет «нет».

Рассказ будет про один контентный проект, в котором мне пришлось переделать архитектуру. Ранее была реализована классическая Лампа-схема (Linux-Apache-MySQL-PHP). Но кол-во посетителей прибавлялось и прибавлялось, уже стало подходить к 1М хостов и сервер БД переставал справляться. Первым делом, я предложил докупить еще один серак, но в данном сегменте конвертация в партнерских программах довольно низкая, так что, руководство проекта немного пожмотилось.

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

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

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

Здравствуйте! Если вы подводили итоги за прошедший год, то, возможно, обнаружили, что что-то осталось невыполненным. То же самое и у меня. Поэтому я поставил задачу основательно разобраться с причинами, которые мешают мне продуктивно работать.

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

Как должно работать это приложение?

… но это нормально. Любое проектирование отстой. И всегда будет отстоем.

Если вы мне не верите, давайте объясню…

Ни один проект не переживает встречи с реализацией

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

Данные, которые вы ожидали как обязательные в ответе внешнего сервиса, могут отсутствовать (или быть невалидными). Ожидаемая уникальность может оказаться совсем не уникальной на практике (даже в sha1 когда-нибудь случаются коллизии). Процессы, которые предполагались надежными, будут падать гораздо чаще, чем вы ожидали.

Это нормально.

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

Недостающие данные могут быть сделаны опциональными или заменены умолчальными.

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

Ограничение уникальности можно

Независимо от сферы вашей деятельности ваш статус фрилансера означает, что вам неизбежно придется столкнуться с вопросом: Как должна оплачиваться моя работа? Стоит ли брать деньги за час? За проект? За этап работы? Исходя из стоимости предыдущих проектов? Исходя из потребностей?

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

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

CSS Refresher

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

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

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

Кладбище мессенджеров, на котором обязательно должны оказаться Skype, Viber, WhatsApp, Hangouts, ooVoo, Apple iMessage, Telegram, Line, Facebook messenger и еще сотни мессенджеров, которым только предстоит выйти в ближайшее время.

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

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

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

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

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

Вторая часть здесь.

Начиная с 1970-х уровень экономического неравенства в США сильно возрос. В частности, богатые становились и становятся еще богаче. Для некоторых это является знаком раскола общества внутри страны.

Меня интересует данная тематика так как я сам являюсь одним из создателей экономического неравенства. Я был одним из основателей компании под названием Y Combinator, которая помогает людям основывать стартапы. Практически по определению основатели становятся богатыми людьми, если стартап успешный. И даже если богатство не является единственной целью основателей стартапов, многие становятся таковыми, и лишь единицы — нет.

(начало статьи здесь)

Управление рисками при инвестировании в программистские таланты

С другой стороны — этот эффект не имеет названия; возможно, его следовало бы именовать «десятикрадничеством» — плохие разработчики будут стоить вам отнюдь не незначительного ухудшения производительности труда. Нет, по целому ряду трудноуловимых причин они способны катастрофически саботировать сложную программную систему. Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте. Хуже того, работа по разбору завалов потребует привлечения усилий гораздо большего количества хороших разработчиков, и на более длительное время.

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