Блог Александра Башкирова

ИТ и бизнес, компьютеры и ПО, фото, программирование и просто мысли…

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

Немного про mysql и совсем мало про postgre

Рубрика: Linux

Писал я тут проект на mysql... Причем, не просто набор таблиц и связей - а "все по-взрослому", то есть: триггеры, хранимые, функции. То есть логика на стороне сервера.

Приступая к сему действу - тешил себя надеждой, что получится написать код, который может мигрировать на postgre вообще без правок. И - обломался. Нет такой радости. Более того, от версии к версии mysql в хранимых что-то добавляется (и, видимо, исчезет). А попытка перенести на postgre наталкивается на много ошибок, которые в основном относятся к специфике СУБД. Так что оставил эту идею и принялся ковырять mysql.

Из того, что заметил:

  • динамический SQL в триггерах mysql нельзя. Совсем никак. Даже если вызывать процедуру, в которой есть динамический SQL - будет ошибка. Версия mysql 5.5.
  • Если пишем триггер на таблицу в mysql, суть которого - изменение поля в той же таблице, на которой триггер, то синтаксис будет такой, например:
  • SET new.field = CONCAT (old.field, 'test')

    где new и old - старое и новое состояние полей соответственно

    А если так не написать - то ошибка вылезет.

  • вообще динамический SQL себя ведет странно. Его как бы можно, но через prepare - execute.
  • курсоры ведут себя странно. Есть таблица, из которой выбираю курсором, InnoDB. Пока она была предварительно заполнена - все хорошо. Как только начал в нее писать/удалять - так всё, ша. Задвоение данных. Об это плясал с бубном много... Но ничего лучше не придумал, как проверять в цикле на совпадение с предыдущим значением (костылииина, честно говоря). Но добиться от мускула адекватного поведения не смог. (Рестарт, сброс кешей, чистка кармы и прочее - не помогли).
  • версию mysql можно посмотреть через SQL запрос SHOW version();
Пока что полет продолжается... Ждем новых вестей с полей "разработки для души".

Три статьи на e-xecutive.ru об одном и том же: про KPI и мотивацию на основе показателей.

Рубрика: Работа
Три предельно практические статьи об одном и том же: как разработать систему мотивации на основе показателей (KPI). А проблема по большому счету, совсем не нова. Рано или позно - но "как мотивировать рублем" встает перед каждой компанией. Ну, или перед каждой...

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

И да, в сознательно не включил в подборку ничего про нематериальную мотивацию - не стоит мешать всё в одну кучу.

E-xecutive.ru: Почему российские компании не могут создать «свой iPad»?

Рубрика: Alib.spb.ru

Еще одна статья на E-xecutive.ru, которой хочется поделиться. "Почему российские компании не могут создать "свой iPad"?

Статья неплохая - с точки зрения проблематики. Но немного "никакая" с точки зрения "а что делать-то теперь со всем с этим"? Так как проблема поставлена, а ответов нет.

А как вы повышаете инноационность в ваших компаниях?

И, "чтобы два раза не вставать" - с вашей точки зрения, насколько инновации совместимы с "классикой жанра", типа управления проектами? (вопрос с подвохом, ага).

Екатеринбург. Вид сверху.

Рубрика: Alib.spb.ru

На телефон, с 52 этажа башни Высоцкого =)

Я немного покадрировал... и понял, что идеальный квадратный Екатеринбург выглядит так:

А вообще... город интересный. Сверху видно то, что снизу не увидишь. Например, вот:

Интересно, сколько Жень получило преждложение при помощи этой надписи? )))

А вообще город красивый (извинясь за блики, серез стекло снимал):

Ну и "начало заката" над городом:

Хабр: Что нужно учесть при проектировании системы, чтобы не было мучительно больно?

Рубрика: Работа -> Alib.spb.ru

На Хабре очережная интересная статья: "Что нужно учесть при проектировании системы, чтобы не было мучительно больно?". Статья о том, как много боли можно получить впоследствии, изначально - неверно спроектировав приложение.

Вернее, как "неверно спроектировав". Понятное дело, что когда гипотетическое веб-приложение типа "сайт с некоторыми функциями" делается "для себя" / "для 100 - 1000 пользоваталей", то по большому счету - не очень важно, "синхрон-асинхрон", "прямые права" (не через роли) и т.д. Когда пользователей становится 100 000 - 1 000 000 и выше, эти проблемы начинают "выстреливать", причем - в самый неожиданный момент. Да, кстати, это не только для веба - это в принципе, для многопользовательских приложений. У всех свои "пороги срабатываения проблемы", но то, что проблема "выстрелит" на больших объемах, если её оставить - 100%. Безальтернативно.

Понятное дело, что поначалу никто не планирует "выход на объем", но вот что точно нужно делать в самом начале - как следует проработать архитектуру приложения, с тем, чтобы впоследствии было проще "расшивать" узкие места. Автор статьи, кстати, делает совершенно аналогичные выводы. Не касаясь явно, правда, еще одного момента - а именно объема данных. Косвенно о них говорится в разделе "Масштабирование", но явно - нет. А это, вообще говоря, может быть той еще головной болью. Когда, например, хранилище данных достигает 10000 Тб, и нужно обеспечить быстрый доступ ... или, как вариант, необходимо хранить таблицу в пару-тройку десятков миллионов строк... еще раз скажу, что редко когда на старте думаешь о том, что так будет. Но бывает, и еще как! В одном случае - логирование действий пользователей с ростом их числа съедает всё место, в другом - начинают в систему "заводить" не предназначенный для этого "тяжелый" контент (видео и т.д.). И получается на выходе - тормоза, отказы, 503я ошибка или просто "висим намертво".

Так что мораль: если вы только начали проектировать приложение - думайте о росте. Если приложение уже есть, но в нем еще нет ни пользователей, ни данных - думайте о росте. Потому что если не думать, то "рост" заставит вспомнить о нем сам. И будет существенно больнее.

Случайная фотография

Орфография

Система Orphus
Дизайн от: Templates Next | Адаптация d51x