В нашей прошлой статье — «11 «рецептов приготовления» MySQL в Битрикс24» — мы, в основном, рассматривали архитектурные решения: стоит ли использовать облачные сервисы (типа Amazon RDS), какой форк MySQL выбрать и т.п.

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

Еще раз напомню, что эта статья (как и предыдущая) не является универсальным «рецептом» идеальной настройки MySQL на все случаи жизни. :) Такого не бывает. :) Но искренне верю, что она будет полезной для вас для решения отдельных конкретных задач.

А в конце статьи — сюрприз для самых терпеливых читателей. :)

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

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

Файлы здесь.

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

Многие менеджеры в приватных беседах жалуются на сотрудников. Вроде бы и знающие специалисты, а работу не работают. Более того — часто отнимают время у тех, кто таки работает. Хоть увольняй.
Многие родители жалуются на что-то подобное в отношении детей. И тут уволить уже нельзя.
И сотрудники, и дети, часто действуют похожими способами. Реализация разная, а виды действий — схожие:

• Привлечение внимания
• Борьба за власть
• Месть и личные нападки
• Беспомощность

У каждого из этих видов есть свои формальные признаки и стандартные лекарства.

На прошлой неделе состоялся успешный эксперимент по запуску нового решения для download-сервиса. Один достаточно скромный сервер (2 x Intel Xeon E5620, 64 GB RAM) под управлением Java-приложения собственной разработки принял на себя нагрузку восьми Tomcat'ов, обслуживая более 70 тысяч HTTP-запросов в секунду общей пропускной способностью 3000 Mb/s. Таким образом, весь трафик Одноклассников, связанный с пользовательскими смайликами, обрабатывался одним сервером.

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

Приятного времени суток!

Ох, жуть как зацепила статья alizar Фотографируемся после каждого коммита (Linux, OSX). Но в силу особенностей своей ОС, предложенные решения мне, слегка, не подошли. Проведя немного времени в поисках и не получив искомого результата, было принято решение сделать что-то простенькое (just for fun, with Demonix) для решения данной задачи…

Доброго времени суток, уважаемое Харбасообщество!

Под катом изложена некоторая информация касательно написания расширений для PHP c использованием C++, почерпнутая мной из различных источников (по большей части англоязычных) и ковыряния исходников Zend Engine 2 во время разработки одного модуля для собственных нужд. Так как объем ее достаточно велик, далее я старался быть краток.

Итак, в этой части:

• Внутренний мир Zend Engine 2
• Иерархия типов данных ZE и структура модуля расширения

А вот до C++ в этой части мы так и не доберемся… =)

Маленький дисклеймер: содержимое статьи не есть истина в первой инстанции, не основывается на официальной документации (а есть ли она?) и является моим субъективным взглядом на ZE 2. Тем не менее, в свое время я был бы рад найти нечто подобное на просторах Рунета, дабы сэкономить время на начальных этапах разработки.

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

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

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

Карта

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

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

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо :-)

Данный текст является вольным переводом вики-страницы «Bash pitfalls» по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

В настоящей статье я хотел бы сделать обзор популярных алгоритмов для решения задачи нахождения максимальной общей подпоследовательности или LCS (longest common sequense). Так как акцент сделан на обучении, а не на реальном использовании, в качестве языка для реализации выбран Python, что позволит сократить количество кода и сконцентрироваться на основных идеях.

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

Что за горутины?

Горутина (goroutine) — это функция, выполняющаяся конкурентно с другими горутинами в том же адресном пространстве.

Запустить горутину очень просто:
go normalFunc(args...)

Функция normalFunc(args...) начнет выполняться асинхронно с вызвавшим ее кодом.

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

Сколько вешать в граммах?

Чтобы было проще ориентироваться, рассмотрим цифры полученные опытным путем.

На Хабре уже упоминалась данная тулза, но как-то в контексте других тем.

What is Fiddler?
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and «fiddle» with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.

To debug applications you've written in Java, .NET, or using WinHTTP, see this page.

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

Довольно часто в пользовательском интерфейсе есть кнопки «Сохранить» и «Отмена». Особенно часто эти кнопки используются в формах. Несмотря на то, что в современном мире всё идёт к упрощению интерфейса, но на эти кнопки всё равно есть спрос.

Сегодня я предлагаю разобраться как с помощью KnockoutJS принимать и откатывать изменения для индивидуальных observables так и целых view models.

Знакомые с KnockoutJS сразу могут выдать две ссылки на лучший блог о сабже

• Creating smart dirty flag in KnockoutKS
• Guard your model accept or cancel edits

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

• Dirty flag — не позволяет сохранять изменения, а только сбросить их в начальное состояние.
• protectedObservable — никто не видит изменений observable до тех пор, пока не произойдёт commit. Это ограничение сильно удручает при использовании dependent observables, к примеру.

Ну и к тому же, они нацелены на индивидуальные observable'ы, а хотелось бы работать с несколькими полями сразу.

Под катом детально разберём процесс создания простого механизма, который сделает работу с принятием и отменой изменений простой и прозрачной.

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

В данной статье речь пойдет о том, как подготовить Redis, phpredis (С модуль для php) и phpRedisAdmin для работы на боевом сервере.

Для того, чтобы собрать все полноценно, нам нужно иметь на сервере:

• gcc 4.5.2 (Я компилировал под этой версией, но думаю, что с другими проблем не возникнет)
• Make 3.81 (Опять же, версия не принципиальна)
• php5-dev (Версия должна совпадать с версией php)

После того, как мы убедимся, что все зависимости удовлетворены, начинаем собирать все компоненты.
Нам потребуются:

• Redis 2.4.4 Stable
• phpredis 2.1.3
• phpRedisAdmin

Как это писалось

Одним долгим зимним вечером моя жена играла в Bookworm adventures, и периодически пинала меня по поводу составления слов подлиннее из имеющихся букв. Быстрый поиск по интернету страничек, позволяющих составлять слова из набора букв дал кучу сайтов, которые пытаются делать это на серверной стороне, и один, который делает это на клиентской ява-апплетом. Те, которые составляют слова мощностями сервера либо имеют ограничение на размер набора букв (обычно, почему-то в 8), либо глубоко задумываются, если им послать набор «abcdefghijklmnopqrstuvwxyz». Ява-апплет же имел ограничение в 12 букв, работал шустро и почти подходил (в игре предлагаются 16 букв для составления слов).

Отличный способ освоить Python — учебный класс Python в Google Code University. Уроки для этого класса написал Ник Парланте из Стэнфорда, и прошедшие курс люди отмечают не просто высокое, а фантастически высокое качество уроков.

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

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

Многие из нас имеют аккаунт в сервисе Dropbox, о данном сервисе написано много статей и лайф-хаков, но сегодня я хочу вам показать, как можно заполучить заветный e-mail в зоне .edu за 15 минут.

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

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

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…