2
Karma
0
Rating
Александр Спиридонов @Sipidronov

Пользователь

Написание собственного неплохого менеджера памяти

Написание собственного неплохого менеджера памяти

Хороший код до Google не доведет

+1
В том-то и беда. Мастер не может указывать, что делать. Он подсказывает, как ту или иную практику аджайла лучше сделать здесь и сейчас (e.g. борду организовать поможет, ретроспективу\постмортем в конструктивном русле поможет сдержать).

На психоаналитиков похожи, на мой взгляд =D

Хороший код до Google не доведет

Хороший код до Google не доведет

0
А вот даже и не менеджерские =D Его задача фа-си-ли-ти-ро-вать аджайл практики в команде, простиоспади.

Хороший код до Google не доведет

0
Это мне? Про тим-лида? Можно как-то перефразировать — я не уверен, что правильно понял ответ.

Хороший код до Google не доведет

0
Да-да, об этом и речь. Все дальше тим-лиды уходят от работы В команде в сторону работы С командой (i.e. внешне по отношению к команде). Лишь бы не перестали говорить на одном языке с инженерами =)

Хороший код до Google не доведет

+1
Я придерживаюсь мнения, что «изучать фреймворки» полезно для поиска новых концепций (e.g. ECS, Sagas — из последнего для меня). Но в то же время есть фреймворки достаточно устоявшиеся и их специфику лучше знать.

Хороший код до Google не доведет

0
О, не, конечно, «не любить людей» — это я утрирую =) Просто мне кажется для поддержания здорового климата в команде нужно что-то большее, чем просто «способность к конструктивному диалогу по необходимости».

Про расслоение — понял, интересно. Спасибо.

Хороший код до Google не доведет

0
Такие ощущения и были, да. Вот только «возможностей для роста» я тут не вижу — просто «растянули» существующие позиции.

Ну, и в качестве отвлеченного замечания: это что же, теперь синьор еще и людей любить должен?!!!

Хороший код до Google не доведет

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

Т.е. вряд ли без ущерба для здоровья можно совмещать тимлида и супер-синьора. Либо я таки чего-то не понимаю.

Хороший код до Google не доведет

+1
После прочтения списка софт-скилов (особенно про «взять под крыло всю команду») возник вопрос: а что в этой парадигме остается тим-лиду? Или позиция тим-лида окончательно откатилась в менеджерскую сферу и с командой-аджайлами-проектированием уже никак не связана?

В России появился законопроект о предоставлении данных пользователей соцсетей неограниченному кругу лиц. Соцсети против

0
Вот, кстати, сходил проверил (имею открытые аккаунты и на фб, и на вк) — гугл имеет очень ограниченную (или не имеет вовсе — фб) информацию о профиле. И это совпадает с тем, что я слышал раньше: фб и гугл давно делят информацию о пользователях для конкуренции в таргетировании.

Так вот, если я правильно понял, предполагается законодательно сделать публичные аккаунты — публичными для всех и в полном объеме. Гугл одобряет =)

Семантика копирования и управление ресурсами в C++

Путеводитель по Швейцарии

+2
Ну, довольно сложно быть обманутым, если уведомление о запланированном списании у меня выплывает в мобильном банке ~ за неделю до фактического списания =)

Путеводитель по Швейцарии

0
Все сходится, да =) Но надеюсь, воспоминания от собеседования остались не самые плохие?

Путеводитель по Швейцарии

Путеводитель по Швейцарии

0
В Недерландах ровно так же многие контракты могут оплачиваться «direct debit»-ом. Сильно упрощает жизнь

Grandstream Networks выпустила бесплатное приложение для SIP телефонии

+1
> позволяет пользователям отслеживать АТС при быстром наборе помощью до 24 виртуальных BLF-клавиш.
> включая передачу вызова
> запись вызова
> Стандартный SIP-программофон

Пожалуйста, попробуй Google-translate — мне кажется, он лучше переведет в автоматическом режиме.

Как я создавал мобильный файтинг под iOS

Небольшое исследование по использованию функторов в стандартной библиотеке STL С++

Небольшое исследование по использованию функторов в стандартной библиотеке STL С++

KernelCare: патчим ядро «на лету»

+1
Ага, понял. Пара мнений:
1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)

KernelCare: патчим ядро «на лету»

+1
Patch Level 9 applied

Это очень энтерпрайзно, конечно, но вопрос есть: какие все-таки ограничения у продукта? Какого рода патчи он не сможет применить?

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

Как-то так, наверно

Анонсирован GNU Free Call — свободная замена Skype

0
Нужно будет, как в Европе в Скайпе, только зарегистрировать аккаунт в системе (если не будет чего-то типа OpenId) и запустить клиентскую программу.

Анонсирован GNU Free Call — свободная замена Skype

0
Безусловно, есть методы заставить работать SIP в, думаю, любой топологии. Вопрос в том, надо ли?

Анонсирован GNU Free Call — свободная замена Skype

0
> Опять неверное утверждение.
Я не про общий случай, а про ситуацию, когда нат задает соответствие srcHost:srcPort — dstHost:dstPort. Как работает в общем случае я прекрасно знаю.

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

Два хоста за симметричным НАТом, действительно, нерешаемая задача без использования дополнительных узлов. И TURN тут был бы актуален.

В итоге мы бы получили только одну исключительную топологию, а не неопределенное количество =)

Анонсирован GNU Free Call — свободная замена Skype

0
ZRTP — конкретная реализация Sercure RTP. Так что, по-прежнему, необходимо установить SIP сессию и в ней объявить медиа-порты. Затем гнать медиа уже в новом UDP-соединении.

Никакого туннелирования ZRTP не предполагает.

Анонсирован GNU Free Call — свободная замена Skype

0
Не надо бороться с НАТом — это борьба с ветряными мельницами =) Он (НАТ) должен быть прозрачен для системы, тогда это перестанет быть головной болью.

Анонсирован GNU Free Call — свободная замена Skype

0
STUN работает, если находится на том же хосте, что и целевой. Будем поставлять STUN сервер с каждой клиентской софтиной? Да и как я уже отвечал, для чего придумывать костыли, когда протокол жестко не предопределен?

P.S.: Для однозначности, я пользуюсь терминологией из вики.

Анонсирован GNU Free Call — свободная замена Skype

0
Здорово, хорошее расширение. Но TURN предполагает, на сколько я знаю, наличие некоего релея для проксирования трафика. Кто будет выступать в его роли в нашем случае?

Так или иначе, что при использовании SIP, что Jingle придется приделывать костыли, надеясь, что все варианты топологий будут перекрыты. Мне кажется, логичнее было бы использовать протоколы совмещающие сигнализацию и медиа и задающие рабочие порты на транспортном уровне.

IAX2, как пример решения.

Анонсирован GNU Free Call — свободная замена Skype

0
Действенный вариант, принимается =) Хотя, при наличии SIP TLS\SIPS и SRTP, использовать шфированный туннель только чтобы обойти проблему NAT'а, ИМХО, нелогично. Все-таки средства надо выбирать сообразно поставленным задачам.

Анонсирован GNU Free Call — свободная замена Skype

Анонсирован GNU Free Call — свободная замена Skype

0
Настраиваемая величина. Я говорю про Linux, но должно быть актуально и для остальных систем (здравый смысл подсказывает)

Анонсирован GNU Free Call — свободная замена Skype

0
Мы говорим про нат =) А у него, во-первых, есть «окно» в течении которого мап актуален и, во-вторых, keepalive'ы слать никто не зпрещает.

Хотя да, у UDP нет такого богатства состояний соединения =)

Анонсирован GNU Free Call — свободная замена Skype

+1
SIP — протокол, исключительно, сигнализации. Посему, порт, через который устанавливается SIP-сессия и порт для меди-данных не могут совпадать.

Приведенный в примере нат задает соответствие srcHost:srcPort — dstHost:dstPort.

Анонсирован GNU Free Call — свободная замена Skype

0
А во время установления сессии клиент еще не знает, как смапится его медиа-порт в случае соединения со вторым участником.

Можно конечно в поставку включать индивидуальный STUN сервер. Но это тоже не решает проблему Port-restricted cone NAT.

Анонсирован GNU Free Call — свободная замена Skype

Анонсирован GNU Free Call — свободная замена Skype

Анонсирован GNU Free Call — свободная замена Skype

0
Это тоже полностью не решает проблему =) «Мы» все еще находимся за натом и «узлу с реальным ипом» все еще нужно угадать, где же мы ловим его медиа-трафик.

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

IAX2, как пример решения.
1 There