• Как правильно использовать исключения
    0
    Этот код будет отлично работать на больших нагрузках. Потому что по одному счету не будет даже 100 обращений в секунду (если будет, то это становится центральным моментом проектирования и код нужно писать иначе, а здесь в примере — это погрешность — это код для 98% биллингов, но не для высокочастотного трейдинга). А заявление о том, что что-то дорого само по себе — ни о чем. Дорого или дешево может быть только относительно.

    А спорить о транзакциях и блокировках с вами я больше не буду — это долго и бессмысленно. Проходили, знаем.
  • Как правильно использовать исключения
    0
    Ответ псевдокодом (субъективно):

    function transferMoney(value, fromWalet, toWalet) {
      lock(fromWalet); // throws CantAquireLockException after timeout
      try {
        if (!fromWalet.hasFunds(value)) {
          throw new InsufficientFundsException(fromWalet, value);
        }
        try {
          SomeTransactionalSystem.begin();
          fromWalet.addFunds(-value);
          toWalet.addFunds(value);
          SomeTransactionalSystem.commit();
        } catch (Exception e) {
          SomeTransactionalSystem.rollback();
          throw e;
        }
      } catch (Exception e) {
        unlock(fromWalet);
        throw e;
      }
      unlock(fromWalet);
    }
    


    Таким образом transferMoney становится полностью самостоятельной процедурой, которая делает свою работу, ничего не возвращает и кидает исключения, когда не может ее сделать. Она не нуждается в блокировках на уровне выше. При этом никто не мешает на уроне выше повторить проверку fromWalet.hasFunds(value), что бы не доводить до исключения. Просто это будет вне блокировки и при параллельной работе с одним fromWalet может возникнуть ситуация, когда InsufficientFundsException все же вылетит.

    или возвращать класс, содержащий информацию об ошибке?

    Возвращать что угодно, содержащее сообщение об ошибке, должен только метод на подобии getError или getLastError. Есть 2 варианта — проверка (валидация) (никаких исключений и возврат true/false) и выполнение (в случае ошибки — исключение). В данном случае я бы предпочел сочетание обоих, т.е. сначала проверить fromWalet.funds < value, потом вызвать transferMoney. Проверка прямо скажет true/false
  • Как правильно использовать исключения
    +6
    Вот то, что я рассказал бы про исключения тому, кто пока не умеет ими пользоваться.

    • Исключения нужно использовать тогда и только тогда, когда возникает развитие событий, не предусмотренное нормальным ходом работы приложения — исключительной ситуации. При этом причина может быть как статической (например, логическая ошибка в коде), так и динамическая (например, недоступность ресурсов).
    • Исключения нужно кидать максимально точно (узко) типизированными.
    • Исключения замечательны для решения своей задачи — прерывания процесса с информированием о возникшей проблеме — причине прерывания, потому что они всплывают по стеку до нужного места. Для других задач они не подходят.
    • Обрабатывать исключения нужно там, где их одновременно возможно и уместно обработать.
    • В прикладном ПО большинство бросаемых на практике исключений не обрабатываются, перехватываются в самой высокой точке стека и попадают в лог, а пользователь получает ошибку 500 «Что-то пошло не так».
  • Запуск услуги «Виртуальное приватное облако»
    0
    Забыл сразу посчитать стоимость за публичный IP, так что вношу изменения в калькуляцию и итоговый текст. :(

    1 ядро CPU — 370 руб.
    1 Гб памяти — 148 руб.
    8 Гб диск — 54 руб. (для 323 руб. для быстрого)
    10 Гб трафика — 0 руб.
    1 IP — 101 руб.
    (Цены я округлил до рублей.)

    Итог — 681 рубль с базовыми дисками. Т.е. получается цена примерно то на то как и в старом облаке, но заметно медленнее, особенно (я предполагаю) по диску. С быстрым диском получается 941 рублей, что уже на 30 % дороже, чем старое облако. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.

    Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные более-менее, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
  • Запуск услуги «Виртуальное приватное облако»
    0
    Могу предложить сравнение по цене для моего мелкого сервера, который работает в старом облаке у кушает 650 рублей в месяц.

    Потребление процессора в среднем около 10 % от одного ядра. В пиках больше 1 ядра не жрет, так что можно рассчитывать на 1 ядро для VPC, хотя может это и не корректно, учитывая что в старом облаке мне были доступны 8 ядер в любой момент времени, а тут будет только одно, чего может оказаться мало при резкой нагрузке.

    Память. Используется MoD, но в среднем на 1 Гб висит.

    Диск — 8 Гб. Запросы к диску и трафик с ним значения для сравнения цены с VPC не имеют, но так как нагрузка малая, сравнивать буду с базовым диском. Впрочем, это тоже не совсем корректно, потому что скорость диска в старом облаке явно выше скорости базового диска в новом.

    Сетевой трафик — ~10 Гб, использовался 1 IP.

    Этот сервер, напомню, ежемесячно обходится в среднем в 650 рублей.

    Теперь рассмотрим во что обойдется аналогичный сервер (только менее резиновый) в случае VPC.

    1 ядро CPU — 370 руб.
    1 Гб памяти — 148 руб.
    8 Гб диск — 54 руб. (для 323 руб. для быстрого)
    10 Гб трафика — 0 руб.
    (Цены я округлил до рублей.)

    Итог — 570 рублей с базовыми дисками. Т.е. получается чутка дешевле, чем в старом облаке, но заметно медленнее, особенно (я предполагаю по диску). С быстрым диском получается 840 рублей. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.

    Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные, получается даже ниже, чем в старом, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
  • Запуск услуги «Виртуальное приватное облако»
    0
    Жалко, что убиваете «Облачный сервер». Для вас эта услуга, наверное, не сильно выгодна. А вот для клиента как раз наоборот — выгодна. Оплата только за фактические потребленные ресурсы — очень хорошая штука для машин с малой степенью утилизации, но с большими пиковыми нагрузками. Там было 8 ядер на машину доступны, а в VPC если машину на 8 ядер брать, это будет просто золотая машина — будет дороже более чем в 10 раз при малом потреблении. Т.е. «Облачный сервер» — это была ниша. И было бы круто ее оставить. Но, повторюсь, для вас (как и для других облачных провайдеров — я не знаю, у кого еще такое есть) скорее всего такой сервис малорентабелен. MoD тоже хорошая штука.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Ага, по крону удалить успешно закачанный файл…

    А представьте, что мы не файлы закачиваем, а серверы выдаем. Или что-то еще дороже.

    Нет здесь косяка — надежное соблюдение бизнес-логики — это обязательное требование. Или можете считать так: в моем примере это именно обязательное требование со стороны бизнеса.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    –1
    Вытекающие будут из serializable. А на счет read committed + select with shared lock, это уже несколько другая плоскость. Тут требуются явные дополнительные действия (как и в случае с обычными писсимистическими блокировками вне БД). Ну и требуется отлавливать падения на дедлоках (именно так оно выглядит в случае MySQL) и запускать транзакцию снова и снова, пока она таки не пройдет успешно. Об этом надо как минимум знать. И это не всегда удобно. А у 51 % опрошенных «этот вопрос вообще никак не стоит».

    Оба решения имеют свои плюсы и минусы. Оптимистические блокировки не всегда лучше, чем писсимистические. А когда мы выходим за пределы БД, использование транзакций для синхронизации может стать проблемой. Так что в идеале нужно выбирать каждый раз индивидуально. И с этим могут быть проблемы, потому что мало кто из PHP-программистов на столько хорошо владеет темой, как, например, вы.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Ну то есть либо выбрать другой уровень изоляции (для MySQL в данном случае потребуется SERIALIZABLE со всеми вытекающими), либо выбрать другое решение.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    –1
    Ниже уже разобрались, что для MySQL с уровнем изоляции по умолчанию это не так.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Истину глаголите в частном случае. Но в общем случае, надо отметить, что данное ограничение на количество висящих коннектов у меня существует не для и не только из-за блокировок. Даже если бы не было ни единой блокировки, все равно была бы эта защита от DoS. Т.е. я не плачу дополнительно, а просто пользуюсь и так работающим функционалом.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    –1
    Если это веб-интерфейс, то скорее всего лучше будут асинхронные запросы на проверку каждого агента отдельно. Тогда если один или несколько агентов будут долго отвечать, это будет видно интерактивно.

    А вот если это консольное приложение, демон (сервис)… Тут момент такой, что ждать ответа по сети можно и асинхронно. Для этого не нужно заводить треды. Тот же eventloop отлично подойдет. Особенно, если агентов много (ну сотни, например). Ну под линуксом во всяком случае. Треды они все же нужны для активной работы, а не пассивной, имхо. Но тут я могу быть неправым, т.к. сам-то их никогда почти и не юзал…
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Если погрешность допустима, то можно просто использовать неблокирующее решение, в чем проблема-то?

    Погрешность допустима при подсчете количества запросов, которые могут работать одновременно для пользователя и/или IP. Будет их 10 или 12, разницы никакой (ну ~100 Кб памяти разница на время таймаута блокировки). А вот если применить неблокирующее решение задачи, то мы получим взлом системы — юзер загрузит больше файлов, чем можно. Это уже проблема. Ну или я неправильно вас понял. Потому что если под неблокирующим решением вы понимали lock-free алгоритмы, т.е. тот же CAS, то такое решение я уже выдавал в самом начале — UPDATE table SET fact = fact + 1 WHERE id=1 AND limit > fact + affected rows.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    А блокировки можно делать штатными средствами MySQL, без flock и т.д.

    Ну это если MySQL есть :) Ну и возможности блокировок там все же ограничены.

    Через несколько лет возможно появится в проектах.

    Спрос очень мелкий… А проблем оно может притянуть массу. Так что может и не появиться. Вот какие реальные юзкейсы, где многопоточность выиграет у многозадачности (=многопроцессности)?
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Так вот достаточно добавить ограничение на количество открытых динамических запросов с одного IP и/или от одного пользователя.
    … и как вы его сделаете без транзакции?

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

    У меня такая штука сделана без синхронизации и без транзакции, я ее тестил через ab, результаты были очень хорошие.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    –1
    В MySQL много чего кривого, но только работает она быстро и жрет относительно мало. Плюсов тоже хватает. И ей дефакто пользуются практически все PHP-девелоперы. А весь топик посвящен именно PHP-девелоперам.

    Можно углубляться сколько угодно, только вот у задачи со счетчиком есть конкретное решение, которое будет прекрасно работать и под нагрузкой (и я не согласен, что нагрузка и блокировки не совместимы). Так как в данном примере мы блокируем только одного пользователя, и это защита от взлома, она не будет проявляться при нормальной работе. Так вот достаточно добавить ограничение на количество открытых динамических запросов с одного IP и/или от одного пользователя. Первые N запросов от него действительно будут поедать память сервера и «висеть» на блокировке, но после превышения лимита запросы будут сразу отваливаться. А ожидание блокировки должно быть определено таймаутом, после которого и ждущие будут тоже отваливаться. Ну и не нужно делать блокировки, которые будут висеть десятки секунд. И транзакции тут тем более не подойдут. Когда время ожидания большое, нужно действовать асинхронно.

    Сделав все правильно, оно будет хорошо работать под большой нагрузкой, под которую вообще имеет смысл писать PHP-приложение. Вон тот же Хабр, например.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    А вот при попытке повторить тоже самое при SERIALIZABLE я уже как и ожидалось получаю блокировку, а в итоге второй запрос получает:

    #1213 - Deadlock found when trying to get lock; try restarting transaction 
    


    Причем, запрос на модификацию значения во второй транзакции висит на блокировке, пока не я изменю в первой транзакции значение. А как только выполнил UPDATE, в тот же момент вторая транзакция отвалилась с обозначенным выше сообщением о дедлоке.

    Опять же копипаст из консоли
    mysql> SET SESSION tx_isolation='SERIALIZABLE';
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> START TRANSACTION;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SELECT `limit`, fact FROM users WHERE id = 1;
    +-------+------+
    | limit | fact |
    +-------+------+
    |     2 |    3 |
    +-------+------+
    1 row in set (0.01 sec)
    
    mysql> UPDATE users SET fact = fact + 1 WHERE id = 1;
    Query OK, 1 row affected (0.00 sec)
    Rows matched: 1  Changed: 1  Warnings: 0
    
    mysql> COMMIT;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SELECT `limit`, fact FROM users WHERE id = 1;
    +-------+------+
    | limit | fact |
    +-------+------+
    |     2 |    4 |
    +-------+------+
    1 row in set (0.00 sec)
    
    mysql>
    



    Так что точно могу сказать, что здесь все совершенно не тривиально, как это кажется изначально. SNAPSHOT isolation и READ COMMITTED SNAPSHOT в MySQL не. (MySQL — это default СУБД для PHP-разработчика.)
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    REPEATABLE READ ничего не блокирует. А SERIALIZABLE блокирует. Об этом написано. И это прослеживается на практике. Ниже в спойлере копипаст из консоли mysql. После первого селекта в другой консоли было изменено значение fact на 2. Как видно, UPDATE в данной странзакции сделал его 3-кой.

    Копипаст из консоли mysql
    mysql> START TRANSACTION;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SELECT `limit`, fact FROM users WHERE id = 1;
    +-------+------+
    | limit | fact |
    +-------+------+
    |     2 |    1 |
    +-------+------+
    1 row in set (0.00 sec)
    
    mysql> UPDATE users SET fact = fact + 1 WHERE id = 1;
    Query OK, 1 row affected (0.00 sec)
    Rows matched: 1  Changed: 1  Warnings: 0
    
    mysql> COMMIT;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SELECT `limit`, fact FROM users WHERE id = 1;
    +-------+------+
    | limit | fact |
    +-------+------+
    |     2 |    3 |
    +-------+------+
    1 row in set (0.00 sec)
    



    И я еще раз подчеркиваю, что да, возможности синхронизации через БД тут есть, но:
    1. они не работают по умолчанию, т.е. нужно менять уровень изоляции;
    2. требуется такой уровень изоляции, который под нагрузкой все уложит и преведет к дедлокам на дедлоке в случае MySQL.


    Так что не делая здесь хоть какую-то явную блокировку, получаем дырку. А теперь вопрос, в каком количестве случае это делается правильно, а об этом даже не думают?
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    –1
    Транзакция внутри себя использует блокировки

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

    Кстати, в задаче со счетчиком достаточно уровня изоляции repeatable read.

    Не достаточно. Очень легко запустить приведенный по ссылкам выше код на любой машине, где есть PHP и MySQL. А после просто удалить файл и выполнить блок очистки, чтобы мусора не осталось. Попробуйте запустить его с уровнем REPEATABLE READ.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Нет, не тривиально. Несколько запросов параллельно могу сравнить и получить разрешение на закачку. И, соответственно, закачать. Решение здесь есть через UPDATE… fact=fact+1… WHERE id = x AND limit < fact, а потом посмотреть affected rows — если оно больше нуля, то принять закачку. Но это не тривиальное решение. И я не думаю, что все повально им пользуются.

    Причем, это вообще будет работать только если есть fact. А если нет, то нужно вести подсчет на лету, и это уже не прокатит.
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Про гит удалил пример, добавил про счетчик. Интересно, что скажете по этому поводу?
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    Вот интересно. Большая часть участников опроса полагается на транзации. Гораздо меньше людей используют блокировки. 55 % сообщают, что вопрос блокировок у них не стоит вообще. Но при решении проблемы с файлом, которая приведена в примере (т.е. проблема счетчика-ограничителя в общем случае), транзакция поможет только при уровне SERIALIZABLE. А это убивает производительность. Кроме того, по умолчанию в MySQL стоит REPEATABLE READ. Не думаю, что все повально его меняют на SERIALIZABLE. А это очень распространенная задача.

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

    Воспроизвести пример и поэксперементировать с ним можно с помощью этого:
    test.php
    test.sql

    Это очень странно, учитывая, что 40 % опрошенных отметили, что разбираются в теме.

    Как задача счетчика-ограничителя решается у вас?
  • Опрос: как у вас решается проблема синхронизации параллельных запросов на PHP?
    0
    На примере гита я хотел показать другое, не вопрос потери данных. Но пример действительно получился плохим. Надо придумать другой…
  • Классификация знаний в области программирования
    0
    Это не минимум, это максимум :)
  • Классификация знаний в области программирования
    0
    Знать можно по-разному. Если обзорные знания по всем областям реально можно получить (а нужно ли сразу по всем — имхо индивидуально), то глубокие знания по всем ним получить уже просто физически не реально, и не нужно. Получить обзорные знания по любой дисциплине на схеме можно прочитав одну хорошую книгу. Причем, общую базу все изучают в школе, а из того, что выше большую часть — на всех более-менее программерских специальностях в ВУЗах.
  • Классификация знаний в области программирования
    0
    Наверное, криптографию нужно было всадить на 1-м уровне с опорой на обработку информации. Могу ошибаться, но мне кажется, что вне экспертного уровня это небольшая область знаний. А вот самая соль и криптографии, и безопасности как аспекта во всех других областях знаний, должна проявляться на экспертном уровне, который я вообще не раскрывал, обозначив лишь 3 примера.
  • Классификация знаний в области программирования
    0
    Я примерно в вашем возрасте за все это основательно и взялся. :)
  • Классификация знаний в области программирования
    0
    Владеть математикой должен математик. Электротехникой — электротехник. Программисту достаточно обзорных знаний в областях, далеких от непосредственно применяемых в работе. И уж тем более речи нет о том, что программист должен знать все, перечисленное на схеме (плюс еще то, что я упустил :)). Но все же чем больше знать будет, тем будет для него лучше, это уж точно. Не сейчас, так через 10–20 лет, когда нужно будет конкурировать с молодыми.
  • Классификация знаний в области программирования
    +6
    ИМХО: годы опыта заменяют месяцы обучения. Я это и на своей шкуре прочувствовал, и по коллегам вижу. По моим прикидкам, если бы я пошел по схеме снизу вверх в универские годы (а не сверху вниз, как вышло на практике), то сэкономил бы несколько лет опыта, которые ушли на получение знаний через практику.
  • Классификация знаний в области программирования
    +1
    Да, потому что в этой классификации «веб-технологии» — это более узкое понятие, чем обычно имеется в виду:

    веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);


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

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

    Я не силен в кибернетике и скорее всего ее отсутствие — упущение. А вот что касается управления командами и проектами, т.е. элемента менеджмента, я не согласен. Во-первых, это реально нужно в практике тем, кто собирается стать даже на самую нижнюю ступень руководства. Во-вторых, программисты работают в проектах по какой-то системе. Если взята готовая модель, программисты должны понимать, как она работает, даже будучи ее объектом. Ну а если модель формируется в команде эмперически, то тем более лучше иметь какие-то знания в этой области, чтобы сделать лучше.
  • Классификация знаний в области программирования
    +7
    Чтобы целиком одним махом закрыть сети, ОС и железо, я могу порекомендовать:
    • Архитектура компьютера, Таненбаум
    • Компьютерные сети, Таненбаум
    • Современные операционные системы, Таненбаум


    А по программированию классику. Чистый код (или Совершенный код — дело вкуса), Рефакторинг, что-то по паттернам, Программист-прагматик, книги Джоэла Спольски. Ну и, конечно, книги по своим языкам и технологиям.
  • Классификация знаний в области программирования
    +3
    Мне кажется, что вы знаете из этого всего больше, чем думаете, что знаете :)
  • Сам себе AWS. Часть 1
    0
    Нужны 2 физических сервера, или это могут быть 2 виртуалки? Но даже если вириуалки, все равно один физический сервер из облока теряется…
  • Сам себе AWS. Часть 1
    0
    На сколько такое решение подходит для организации облака на серверах без выделенного хранилища? Т.е. есть несколько мощных серверов с дисками в каждом. Нужно запустить на них облако, причем желательно, чтобы ни один сервер не вышел из полностью эксплуатации (т.е. не выделился под нужды самой системы облака).

    OpenStack как ни крути сложная штука. Чтобы ее использовать, нужно хорошо в ней разобраться. Это все понятно. Но вот где бы найти хороший и современный обзор ее возможностей, чтобы начинать с общей картины, а не подробностей.
  • Синхронизация закладок в Opera Developer
    0
    Ну да, надо немного сменить образ работы. Он отличается. Но тут фишка в том, что Evernote (или другая утилита такого плана) — это полноценное хранилище информации, а заметки в Опере — свалка. Переходите на новый уровень. Мучаться придется недолго, потом привыкните и будет профит :)
  • Синхронизация закладок в Opera Developer
    0
    Мне заметки в свое время заменил Evernote, чем я сейчас очень доволен, ибо им пользоваться оказалось удобнее :) Но как основной браузер для серфинга на работе у меня по прежнему 12-я Опера (не из-за заметок, конечно).
  • YaC 2014: главная технологическая конференция Яндекса для тех, кому она действительно нужна
    0
    Спасибо за ответ по существу.
  • YaC 2014: главная технологическая конференция Яндекса для тех, кому она действительно нужна
    +5
    Жаль, что ответа по существу вопроса нет… Ну да ладно. Ваша аналогия ясна. А я на базе вашего примера, аналогию выверну. Наверное, правильно сделали в итоге, что убрали из ОС то, чему не место было в ней. Наверное в следующем году в аналогичном посте вы сформулируете мысли корректнее.

    А про личную обиду — это вы чтобы добить? Только голова всплыла, а вы ее назад толкаете? Я, честно говоря, несколько обескуражен таким отношением.

    Я то как раз не PHP-шник, Григорий, не смотря на использование этого инструмента в работе. Ваше суждение, похоже, как раз шаблонно и стереотипно. Открыли профиль, увидели там php, и — бинго! Все сразу ясно :)

    А про позицию компании мне действительно интересно, какое же отношение к людям на купленных проектах, и какое отношение людей к компании при таком подходе…
  • YaC 2014: главная технологическая конференция Яндекса для тех, кому она действительно нужна
    +3
    Интересно, цитата ниже — это позиция компании, или личное мнение сотрудника, ответственного за написание этого поста?

    Специалист непонятного профиля. Вот типичный PHP-программист — это программист суперширокого профиля, то есть не специалист ни в чем. Я уточню сейчас, что это типичный программист, потому что есть нормальные PHP-программисты. Их просто очень мало.


    Мне кажется, что рамки приличия вы переступили в данном случае. Надо уметь свои мысли выражать по-корректнее, особенно в местах, где, наверное, процентов 80 — как раз те, кого вы только что чем-то облили :)