[Moscow.pm] Ищем сеньер perl программиста в стартап. (удаленка).

Alex Chistyakov alexclear на gmail.com
Пн Ноя 9 06:59:09 PST 2015


2015-11-09 17:40 GMT+03:00 Dmitry Eremeev <dmitry на eremeev.ru>:

> Слишком много предъяв, в основном не по делу.
>
> По делу же, для 99% задач (сайты, обычный или мобильный web, вот это все)
> подходят уже готовые решения, даже обсираемый MySQL, ибо:
>

С этим совершенно согласен.



> 1. “Папа железа докупит” (кто помнит описалова того, как были устроены
> написанные на JAVA “Одноклассники" - тот поймет).
>

А?
И чем же были не так устроены написанные на Java "Одноклассники"?
То, что средний подписчик Moscow.pm до сих пор не в состоянии осознать
отличия Perl от Java - не означает, что Java плохой язык, или
"Одноклассники" были устроены как-то неправильно (если и были - то не в
очевидных перловику местах).



> 2. Пока розробочеги умничают, у инвесторов успевает кончиться бабло до
> скачка реальной посещаемости.
>
>
> В особых случаях (например real-time аналитика или рекламные сервисы)
> приходится изъебываться так, что коробочные истории просто не подходят
>

Если мы под коробочными решениями имеем в виду MySQL, Redis и MongoDB - то
да, наверное, не подходят. Использование этих трех в рекламных сервисах я
себе еще как-то представляю, а в real-time аналитике - уже нет.



> , для чего приходится строить собственные решения, которые потом нигде не
> задействуешь.
>
>
>
>
>
>
>
>> Yours
> Dmitry Eremeev
>
> On 9 November 2015 at 17:23:32, Alex Chistyakov (alexclear на gmail.com)
> wrote:
>
>
>
> 2015-11-09 17:19 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> > Минимизировал участие MySQL в пользу REDIS там, где нет длинных
>> портянок в
>> > таблицах и NoSQL лучше подходит. Зашуршало.
>>
>> кстати ВЕЗДЕ (кроме случаев server-side шардинга, а сейчас пожалуй и в
>> них тоже) noSQL базы данных проигрывают "монстрам".
>> ибо noSQL пишут как правило полнейшие ламеры и всякий noSQL как
>> правило представляет из себя один-два BTREE индекса и все.
>>
>
> Как правило - не BTREE.
> Вот уж делать BTREE - и правда смысла ноль.
> LSM-tree, как правило.
>
>
>>
>> смысла использования noSQL ровно ноль.
>>
>>
>> у noSQL только одно преимущество и оно не относится к быстродействию,
>> функциональности и так далее.
>> оно относится только к социальному фактору:
>>
>> когда человек пишет на SQL он не всегда понимает что там происходит в
>> хранилище и поэтому очень легко загоняет хранилище в ступор.
>> когда человек пишет на noSQL то он ВЫНУЖДЕН понимать как хранилище
>> устроено и поэтому загнать его в ступор ему трудно.
>>
>> а так, вон Pg давно по бенчмаркам уделывает все эти модные
>> монги/редисы, мало того - еще и масштабируется неплохо по CPU.
>>
>> а server-side шардинг, ну толкового пока никто его не написал ни на
>> редисе, ни на монге, ни на SQL.
>>
>
> Это потому что и редис, и монга - это маркетинговые решения, а не
> технологические.
>
>
>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20151109/7e1d7a32/attachment.html>


Подробная информация о списке рассылки Moscow-pm