...

суббота, 15 июня 2013 г.

«Машина времени» от Foursquare: все ваши путешествия за все время


сегодня в 18:31



Сервис Foursquare вызывает противоречивые чувства у многих людей. Некоторым все это нравится, и очень много интернет-пользователей отмечают места своего пребывания в конкретный момент времени, завоевывают «мэрства» и т.п. Другим же кажется, что лучшего инструмента для отслеживания действий человека, совместно с некоторыми другими социальными сетями, не найти. Тем не менее, у сервиса миллионы пользователей, которым явно должен понравиться такой инструмент, как «Time Mashine»: визуальное отображение всех путешествий пользователя, с инфографикой и спокойной музыкой.


В конце «путешествия во времени» пользователь получает сводку, с кучей статистических данных, о путешествиях и перемещениях данного конкретного человека. «Машина времени» — отдельный сервис, созданный совместно Foursquare и Samsung. ДЛя того, чтобы увидеть все своими глазами, нужно предоставить доступ Timemachine к своему аккаунту в Foursquare.



В общем, довольно интересно, позволяет быстро оценить масштабы своих путешествий.



Via Foursquare Timemachine





Developers, stick with Russians – work in London



Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


пятница, 14 июня 2013 г.

Backdoor в роутерах D-Link


сегодня в 12:11


В роутерах D-Link (DIR-300revA, DIR-300revB, DIR-600revB) обнаружен backdoor.

Немецкий исследователь просканировал некоторые устройства D-Link nmap-ом и обнаружил открытым порт 23\tcp (telnet).


Результаты сканирования nmap
root@bt:~# nmap -sSV -p 23 192.168.178.133,144,222

Starting Nmap 6.01 ( nmap.org ) at 2013-04-30 13:42 CEST

Nmap scan report for 192.168.178.133

Host is up (0.0067s latency).

PORT STATE SERVICE VERSION

23/tcp open telnet D-Link 524, DIR-300, or WBR-1310 WAP telnetd

MAC Address: 1C:BD:B9:A7:7F:74 (D-link International PTE Limited)

Service Info: Device: WAP

Nmap scan report for 192.168.178.144

Host is up (0.0068s latency).

PORT STATE SERVICE VERSION

23/tcp open telnet D-Link 524, DIR-300, or WBR-1310 WAP telnetd

MAC Address: 00:26:5A:38:7D:77 (D-Link)

Service Info: Device: WAP


Nmap scan report for 192.168.178.222

Host is up (0.0031s latency).

PORT STATE SERVICE VERSION

23/tcp open telnet D-Link 524, DIR-300, or WBR-1310 WAP telnetd

MAC Address: 34:08:04:DB:6D:FE (D-Link)

Service Info: Device: WAP




Порсле этого исследователь заглянул в конфиг-файл и обнаружил


код, отвечающий за функцию backdoor

./rootfs/etc/scripts/misc/telnetd.sh

#!/bin/sh

image_sign=`cat /etc/config/image_sign`

TELNETD=`rgdb -g /sys/telnetd`

if [ "$TELNETD" = «true» ]; then

echo «Start telnetd ...» > /dev/console

if [ -f "/usr/sbin/login" ]; then

lf=`rgdb -i -g /runtime/layout/lanif`

telnetd -l "/usr/sbin/login" -u Alphanetworks:$image_sign -i $lf &

else

telnetd &

fi

fi

root@bt:~/firmware/DIR300-extracted# cat rootfs/etc/config/image_sign

wrgg19_c_dlwbr_dir300



Т.е. пароль зависит от того, какая в устройстве версия прошивки. При чём пароль этот даёт root-привелегии к устройству (см. картинку ниже):



Получив рутовый пароль, вы также можете


обнаружить в устройстве логин\пароль к веб-интерфейсу устройства в открытом виде


# cat var/etc/httpasswd

admin:admin

или так:




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


Источник





Developers, stick with Russians – work in London



Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Лечим задержки: включения в 30 точек обмена трафиком и 57 пирингов доступны для Вас!

Ваш сайт нуждается в одинаково хорошей связности, как с Россией, так и с Украиной одновременно? Быть может часть Вашей аудитории в Европе, а часть в США? Вам надоело слышать оправдания ЦОДов — «проблема вне сети Дата Центра и вне зоны нашей ответственности» и получать жалобы пользователей из разных регионов, что у них тормозит просмотр видео на Вашем сайте? Тогда Вам к нам!

Благодаря обширной сети емкостью свыше 3 Тбит / с, включениям более, чем в 30 точек обмена трафиком и 57 пирингам — мы способны решить проблему со связностью и качеством трафика.


В качестве примера приведу рабочую ситуацию.


Один из крупных магистральных провайдеров России GlobalNet, с довольно качественными собственными зарубежными каналами аж до самого Амстердама, начал глючить, в итоге значительная часть пользователей из ленинградской области, в частности клиенты беспроводного 4G Интернета «Йота», начали испытывать сложности с доступом к зарубежному сегменту Интернет, который маршрутизируется через GlobalNet.



Мы сразу же отписали запрос в ЦОД, как только заметили проблему, так как магистральный провайдер не отвечал на наши письма (видимо был занят решением проблемы, так как ранее ответы давались в течении 5 минут):



[root@lw11 ~]# mtr -i0.5 -rw -c100 -s100 -o «LSD ABWJ» 94.25.229.106

HOST: lw11.ua-hosting.com.ua Loss% Snt Drop Avg Best Wrst Jttr

1. hosted.by.leaseweb.com 0.0% 100 0 0.4 0.3 1.4 0.0

2. xe4-0-0.hvc1.evo.leaseweb.net 0.0% 100 0 4.7 0.2 54.0 0.1

3. 85.17.100.170 0.0% 100 0 3.3 1.1 8.9 2.9

4. leaseweb-gblnet-gw.gblnet.ru 0.0% 100 0 3.8 0.9 166.7 0.2

5. ams-sth-te-gw.gblnet.ru 0.0% 100 0 40.3 22.9 274.9 5.6

6. 94.124.182.161 0.0% 100 0 35.1 34.9 36.0 0.0

7. kant12-b57-te-gw1.gblnet.ru 17.0% 100 17 41.7 35.1 212.3 0.7

8. 109.239.128.34 0.0% 100 0 35.4 35.3 35.9 0.2

9. ??? 100.0 100 100 0.0 0.0 0.0 0.0

[root@lw11 ~]#


Can you contact with your PNI gblnet or fix this?





Менее чем через 20 минут был получен ответ:

Dear sir,


This PNI will be shut in next few hours.


Kind regards,


Grzegorz Janoszka





Проверили через 15 минут, трафик уже ходил по другому маршруту:

[root@lw11 ~]# mtr -i0.5 -rw -c100 -s100 -o «LSD ABWJ» 94.25.229.106

HOST: lw11.ua-hosting.com.ua Loss% Snt Drop Avg Best Wrst Jttr

1. hosted.by.leaseweb.com 0.0% 100 0 0.7 0.3 24.6 0.0

2. xe4-0-0.hvc1.evo.leaseweb.net 0.0% 100 0 1.5 0.2 49.3 8.9

3. 62.212.80.125 0.0% 100 0 2.1 0.6 58.3 0.0

4. ae6.RT.TC2.AMS.NL.retn.net 0.0% 100 0 6.1 0.7 63.9 0.0

5. ae6-2.RT.TC1.STO.SE.retn.net 0.0% 100 0 23.0 22.2 68.2 0.0

6. GW-RUNNet.retn.net 0.0% 100 0 33.7 22.5 318.9 0.1

7. kt12-1-gw.spb.runnet.ru 0.0% 100 0 37.7 35.2 196.5 0.1

8. c7606-te4-5-291.gblnet.ru 13.0% 100 13 39.3 35.2 231.1 0.3

9. 109.239.128.34 0.0% 100 0 35.6 35.4 36.0 0.4

10. ??? 100.0 100 100 0.0 0.0 0.0 0.0

[root@lw11 ~]#





Просто, без лишних вопросов… Жалобы сразу исчезли, так как потери на c7606-te4-5-291.gblnet.ru свидетельствовали уже не о проблеме, а лишь о том, что оборудование занято более важными запросами и ICMP-трафик не приоритетен для него.

Подобные проблемы, к сожалению, очень сложно решаются во многих ЦОДах Украины и России, не из-за нежелания помочь, а по той причине, что попросту нет такого количества разных аплинков, через которые можно направить трафик в обход, особенно, если трафика много. А ведь задержки и потери на каналах могут стать причиной снижения аудитории Вашего проекта, потому крайне важно иметь возможность решить такие проблемы оперативно и вообще иметь возможность их решать, так как в данном конкретном случае проблема действительно наблюдалась за пределами ЦОД.


Конечно, реализовать такую связность затратно, тем не менее в ЦОД устанавливается свыше 100 новых серверов ежедневно и количество уже установленных серверов превышает 65 000, потому у Вас есть возможность арендовать выделенный сервер с качественным неограниченным каналом в Дата Центре премиум-качества по невероятно низкой цене:


http://ua-hosting.com.ua/nl-servers.html

Intel Xeon E3-1230 / 8GB DDR3 / 2x500GB SATA2 / 100Mbps Unmetered — $89 / месяц!


Обращаясь к нам Вы получаете:


— серверы с МОМЕНТАЛЬНОЙ активацией в премиум Дата Центре EvoSwitch (Haarlem, Netherlands);

— русскую поддержку 24/7 и решение Ваших вопросов в приоритетном порядке;

— Platinum SLA бесплатно;

— бесплатную базовую настройку;

— отлличную связность с RU / UA / US;

— только гарантированные каналы без учета трафика;

— только серверное надежное железо;

— невероятно низкие цены;

— доступ к сети выского качества общей пропускной способностью свыше 3 Тбит / с!


У серверов очень хорошие каналы на Россию и Украину. Для подтверждения своих слов приведу несколько трасс в Россию (Москва и Питер):


[root@lw11 ~]# tracepath msk-ix.ru

1: lw11.ua-hosting.com.ua (95.211.159.76) 0.081ms pmtu 1500

1: hosted.by.leaseweb.com (95.211.159.126) 0.797ms

1: hosted.by.leaseweb.com (95.211.159.126) 0.576ms

2: xe3-0-3.hvc1.evo.leaseweb.net (82.192.95.232) 0.446ms

3: xe-8-3-2-amt.cw.net (208.173.213.161) 1.035ms asymm 5

4: as5568-gw1.amd.cw.net (208.173.209.2) 1.045ms asymm 5

5: KHOUSE-Relarn-3.Relarn.ru (194.226.29.5) 46.152ms asymm 6

6: KHOUSE-Relarn-3.Relarn.ru (194.226.29.5) 46.825ms !H

Resume: pmtu 1500

[root@lw11 ~]#


[root@evoswitch.ua-hosting ~]# tracert mail.ru

traceroute to mail.ru (94.100.191.241), 30 hops max, 40 byte packets

1 hosted.by.leaseweb.com (95.211.156.254) 0.665 ms 0.663 ms 0.661 ms

2 xe4-0-0.hvc1.evo.leaseweb.net (82.192.95.209) 0.253 ms 0.266 ms 0.267 ms

3 xe1-3-0.jun.tc2.leaseweb.net (62.212.80.121) 0.918 ms 0.930 ms 0.932 ms

4 ae4-30.RT.TC2.AMS.NL.retn.net (87.245.246.17) 0.932 ms 0.934 ms 0.935 ms

5 ae0-1.RT.M9P.MSK.RU.retn.net (87.245.233.2) 44.981 ms 44.993 ms 44.994 ms

6 GW-NetBridge.retn.net (87.245.229.46) 52.378 ms 52.101 ms 52.095 ms

7 ae37.vlan905.dl4.m100.net.mail.ru (94.100.183.53) 52.093 ms 52.086 ms 52.081 ms

8 mail.ru (94.100.191.241) 41.870 ms 42.195 ms 42.181 ms

[root@evoswitch.ua-hosting ~]#


[root@lw11 ~]# tracepath selectel.ru

1: lw11.ua-hosting.com.ua (95.211.159.76) 0.075ms pmtu 1500

1: hosted.by.leaseweb.com (95.211.159.126) 1.030ms

1: hosted.by.leaseweb.com (95.211.159.126) 0.748ms

2: xe3-0-3.hvc1.evo.leaseweb.net (82.192.95.232) 0.393ms

3: 62.212.80.140 (62.212.80.140) 0.843ms

4: ae6.RT.TC2.AMS.NL.retn.net (87.245.246.17) 27.627ms

5: ae7-4.RT.KM.SPB.RU.retn.net (87.245.232.225) 45.644ms asymm 7

6: GW-Selectel.retn.net (87.245.252.86) 36.384ms asymm 7

7: 188.93.16.26 (188.93.16.26) 36.814ms reached

Resume: pmtu 1500 hops 7 back 57

[root@lw11 ~]#


Ну, а теперь покажу связность с моим домашним провайдером в Украине:


[root@lw11 ~]# tracepath o3.ua

1: lw11.ua-hosting.com.ua (95.211.159.76) 0.081ms pmtu 1500

1: hosted.by.leaseweb.com (95.211.159.126) 0.606ms

1: hosted.by.leaseweb.com (95.211.159.126) 0.558ms

2: 85.17.31.250 (85.17.31.250) 0.439ms

3: xe1-3-2.jun.tc2.leaseweb.net (62.212.80.93) 0.843ms

4: ae6.RT.TC2.AMS.NL.retn.net (87.245.246.17) 0.835ms

5: ae2-3.RT1.NTL.KIV.UA.retn.net (87.245.233.57) 44.374ms asymm 7

6: GW3-WNet.retn.net (87.245.237.12) 38.471ms

7: freenet-gw.cs1-dr.kv.wnet.ua (217.20.169.221) 41.656ms

8: 94.76.105.6.freenet.com.ua (94.76.105.6) 41.267ms asymm 7

9: 94.76.104.22.freenet.com.ua (94.76.104.22) 44.139ms asymm 8

10: noc.freenet.com.ua (94.76.107.4) 42.699ms reached

Resume: pmtu 1500 hops 10 back 56

[root@lw11 ~]#


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


Например проксирования:



Или просто отдачи файлов / стримминга:



Хотя конечно для отдачи файлов применяются зачастую кластеры из многих гигабитных серверов, каждый из которых генерирует примерно следующий трафик:



При этом обеспечивается изумительная связность и доставка трафика оптимальным маршрутом для Вашей аудитории. Сколько бы Вы не потребляли трафика, Вас никогда не отключат за «превышение», у Вас всегда будет Ваш гарантированный канал и Вы будете получать оплаченную Вами услугу на 100%.


Присоединяйтесь, арендуйте выделенный сервер в одном из лучших Дата Центров! Уже сегодня Вас ждут много серверов с моментальной активацией после проведения оплаты, в их числе и гигабитные:


http://ua-hosting.com.ua/nl-servers.html


Мы позаботились о том, чтоб Вы имели возможность получить Ваш заказ в минимальные сроки!


Более подробно о ЦОД Вы можете узнать из нашей публикации: http://habrahabr.ru/company/ua-hosting/blog/180851/


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Open SmartWatch Project


сегодня в 11:54






Sony анонсировала проект Open SmartWatch, целью которого является привлечение разработчиков к созданию альтернативных прошивок для своих умных часов SmartWatch.



В рамках проекта, Sony опубликовала спецификацию устройства а также подробную инструкцию по прошивке. Кроме того, был создан каталог, куда планируется добавлять альтернативные прошивки. На текущий момент в каталоге находится лишь одна стоковая прошивка 0.1.B.1.3 — последняя на текущий момент.

При всем этом Sony предупреждает, что использование альтернативных прошивок может привести к лишению гарантии.





Developers, stick with Russians – work in London



Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Встреча-семинар IT Beer Club в Киеве

Напоминаем, что сегодня IT Beer Club

Тема встречи: «Построение комплексной инфраструктуры предприятия любого уровня сложности»

Можно послушать доклады, пообщаться с коллегами.


Цель встречи: неформальное общение айтишников.


Вход – свободный для всех желающих.

Когда: 14 июня (пятница), начало в 15.00

Где: пл. Победы, 3, универмаг «Украина», 4 этаж, Status Party Bar (напротив паба Shultz).

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


Трансляция и видео докладов будет здесь: www.youtube.com/watch?v=LUaEBHyahDg


Под кактом какие будет доклады на встрече:



15:00 – 15:40 Решения Aruba Networks для построения беспроводных сетей

Станислав Петров, Aruba Украина


15:40 – 15:50 серия вопросов/ответов


15:50 – 16:30 Экстремально производительные сети Extreme Networks,

Александр Майстренко, MUK


16:30 – 16:40 серия вопросов/ответов


16:40 – 17:20 Решение комплексной сетевой безопасности предприятия от Fortinet

Лымарь Василий, инженер компании Fortinet


17:20 – 17:30 серия вопросов/ответов


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Что внутри дата-центра повышенной ответственности


В средней части первого этажа ЦОД «Компрессор» два машзала, строго над ними — два машзала на втором этаже. В каждом зале по 1 МВт электромощности на стойки. На первом этаже трансформаторная подстанция, распредпункт, электрощитовая. Слева-сверху на схеме бытовой комплекс, помещение охраны. Справа от машзалов – помещение системы охлаждения – насосная станция. Рядом с машзалами (по бокам) коридоры с фанкойлами, по центру — коридор с распредщитами.


Второй этаж в принципе повторяет планировку первого этажа:



На месте трансформаторных подстанций — ИБП и аккумуляторы. Холодильная часть второго этажа — это насосная станция гликолевого контура (второй контур охлаждения). Плюс справа от машзалов установлен бак-аккумулятор на 100 кубометров на 15 минут автономного холодоснабжения ЦОДа (при отключении внешнего электроснабжения на время запуска дизельной электростанции для охлаждения машзалов используется уже заранее захоложенная вода из бака, которая подаётся в контур охлаждения).




Макет ЦОДа


Вот первый топик про строительство этого ЦОД.


Вводная




Прежде чем идти дальше, для начала коротко расскажу о ситуации. Сейчас у КРОК есть 3 ЦОДа, которые располагаются вот так:


Первые два – у нас в офисе и под соседним зданием парковки соответственно. Третий (как раз «Компрессор») находится подальше, но тоже в Москве, из-за развитой инфраструктуры и хороших каналов связи в столице и из любой точки города. Он расположен там, куда системный администратор или инженер спокойно может добраться минут за 40-50 из любой точки города или из центра на метро или машине.


Вообще, на сегодня мы участвовали уже более чем в 60 запусках ЦОДов разных компаний в России – где-то делали очень много, где-то консалтили, где-то выполняли только отдельный участок работ. Опыт накопился большой. Но начиналось всё просто: первый ЦОД был пилотный, со всеми классическими решениями. На базе него мы для себя поняли, насколько перспективно это направление и насколько аутсорсинговые ЦОДы востребованы. Тогда же мы начали проектировать и строить ЦОД «Компрессор». По ходу дела появилась возможность построить ещё один не очень большой ЦОД под парковкой. В нём впервые в РФ мы использовали ДДИБП (это очень интересный ИБП, где огромный ротор накапливает кинетическую энергию), плюс как на нем, так и на Компрессоре обкатали ещё несколько новых штук.




Первый ЦОД на 90 стоек и 1Мвт.




Второй ЦОД на 110 стоек и 2 Мвт.




ЦОД «Компрессор» на 800 стоек и 8 Мвт.


Базовые параметры ЦОД «Компрессор»


  • Отказоустойчивость: Tier III, подтвержденная Uptime Institute,

  • Охлаждение: N+1, в среднем 5 кВт/стойку (есть и 30 кВт стойки, они ставятся рядом с менее мощными в машзале),

  • Энергоснабжение: 2N, ИБП – 15 минут, ДГУ – 24 часа без дозаправки,

  • Вместимость – 800 стоек,

  • Помещения склада и персонала заказчика,

  • Охраняемая территория,

  • Здание в собственности,

  • Соединен оптоволоконным кольцом с сетью дата-центров КРОК,

  • 6000 кВт общей холодильной мощности, из них 1500 кВт резерв,

  • Сквозное резервирование системы холодоснабжения N+1 (3+1),

  • Среднегодовой расчётный PUE не хуже 1.45,

  • Запас холода 15 минут при отключении электроснабжения,

  • Температурный диапазон -36…+37 градусов (это абсолютный минимум и максимум за последние 10 лет в Москве).





Электроснабжение






Извините, меня предупредили, что если на схеме будет что-то читаться, то безопасники меня пристрелят, поэтому вот так.

Энергоснабжение



  • 8 МВА максимальное энергопотребление ЦОД,

  • 4 МВт (4х200х5 кВт) энергопотребление ИТ,

  • Энергия напрямую от генератора (ТЭЦ-11) по двум независимым кабельным линиям,

  • PUE по результатам замеров из полного потребления ЦОДа (включающего всех потребителей) к IT-стойкам 1,35-1,45 (зима), в отдельные дни было 1,25. 1,45-1,85 (лето). Запланированное среднегодовое – 1,45, идём чуть лучше плана,

  • Крупнейшая в России сборка ДГУ F.G.Wilson в контейнерном исполнении,

  • 7 ДГУ по 2000 МВА каждый,

  • Параллельная работа ДГУ на 2 шины,

  • Резервирование коммуникаций 2N,

  • Резервирование ДГУ N+1,

  • Запас топлива на 24 часа.


Бесперебойное энергоснабжение



  • Крупнейшая в России сборка ИБП GE Digital Energy,

  • 38 шт. GE DE SG series по 300 кВА каждый,

  • Автономия 15 мин,

  • Резервирование сборок ИБП 2N и N+1.


Оборудование



  • Электромонтажное и электрощитовое оборудование Schneider Electric,

  • Релейная микропроцессорная защита Sepam,

  • Распределительные щиты Prisma Plus серий P и G,

  • Шинопроводы Canalis KTA,

  • Кабельная продукция: более 100 км кабеля сечением от 1,5 до 400 квадратных миллиметров (некоторые нельзя согнуть руками, только специальным прибором) от отечественных заводов.



Полные 8 МВт достигаются при температуре +37 снаружи и полной загрузке машинных залов. Вход — 2 линии от ТЭЦ, причём нам пришлось дорабатывать их питающие ячейки и самим прокладывать инфраструктуру до ЦОДа. Затем 8 трансформаторов, 4 группы по 2 штуки. Мы старались минимизировать количество коммутирующих аппаратов. В России один автоматический выключатель на 2,5 килоампера стоит дороже, чем трансформатор. Поэтому мы оптимизировали схему исходя из минимизации затрат. На каждый машзал сейчас работает по два независимых трансформатора по 2000 киловольт-ампер каждый. Нечётные трансформаторы питают чиллеры и градирни, чётные — фанкойлы. Мы имеем возможность отключать любой из трансформаторов, и при этом работоспособность ЦОДа не нарушается. Справа на схеме — 7 резервных ДГУ по 2000 киловольт-ампер резервной мощности. Запас топлива хранится в двух ёмкостях по 25 кубометров.


ИБП — классические статические. 38 штук по 300 киловольт-ампер каждый. Для машзалов резервирование 2N, для инженерной нагрузки — N+1. Обеспечивается 15 минут бесперебойного питания.


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


Охлаждение




Система охлаждения – это баланс между экологичностью, ценой и эффективностью. Да-да, мы любим экологичные решения, и уже тогда думали про это, а не только про деньги.


Система двухконтурная, первый контур с водой — 200 тонн. В случае разлива никаких проблем. Вода ещё и хороша по теплофизическим свойствам. Баки-аккумуляторы у нас из железобетона, давление создаётся естественным столбом воды (система открытая).


Мы закладывали высокие параметры по температуре, чтобы минимизировать потери мощности на конденсации воды на теплообменниках. В нашем случае 13 градусов на подающей 18 градусов на обратной магистрали. В будущем, в следующих ЦОДах (мы их постоянно строим в России) хотим ещё поднимать температуру, можно двигаться дальше.



Внешний контур заполнен этиленгликолем. Чиллеры и драйкулеры включены последовательно — то есть расширяется температурный диапазон работы в режиме свободного охлаждения, можно практически до +15 на улице частично снимать тепло драйкулерами в режиме свободного охлаждения. 100% Фрикулинг с полным съёмом мощности доступен уже при +5 и ниже.


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


Основные параметры:



  • 64 фанкойла STULZ на 4000 кВт мощности. 48+16 резервных. Для экономии мы используем все, что позволяет работать на более тёплой воде.

  • Вода 13/18 градусов Цельсия,

  • Увлажнитель на каждой 4-й машине

  • Мощность 97 кВт (Qявн = Qполн),

  • Расход воздуха 28800 куб.м/ч.


Поставщики:



  • Чиллеры и градирни: Nordvent,

  • Вентиляционное оборудование: LENNOX,

  • Насосное оборудование: GRUNDFOS,

  • Теплообменное оборудование: Alfa Laval,

  • Запорно-регулирующая арматура: BROEN, GROSS.


Под фальшполом нет ничего, кроме труб системы газового пожаротушения, и там ничего не зонируется, работаем на общий объем. Чиллеры все воздушные + «сухие» градирни, включенные в контур последовательно (сначала по потоку стоят градирни, потом чиллеры). Это позволяет расширить диапазон работы системы в режиме полного и частичного фрикулинга.


В предыдущем топике был вопрос по именно такому решению через фальшпол, расскажу чуть подробнее, почему. Работа через фальшпол достаточно эффективна, удобна и конструктивно проста практически для всех современных применений в ЦОДах. Одна из задач, которую мы решали при проектировании инженерных систем состояла в том, чтобы внутри машинных залов не было никакого «постороннего» (не относящегося к арендаторам) инженерного оборудования. Нужно это потому, что если, например, банк размещает у нас стойки, то чаще всего ставит специальные ограждения прямо в машзале. Любое обслуживание оборудования внутри зоны клиента означает необходимость звать их безопасников. Вопросы безопасности наших клиентов превыше всего.


Вторая задача – отсутствие воды в машинных залах и над ними (никаких «внутрирядников» и «холодильников» на перекрытиях). Работая через фальшпол мы обе эти задачи и решили, ведь фанкойлы у нас вынесены из машзалов в специальные боковые коридоры.


Ещё вопрос был про «мегагорячие» стойки. Они охлаждаются на общих основаниях. Рядом с ними ставим «пустые» стойки с заглушками. Есть условие — через одну перфорированную плитку фальшпола в наших условиях можно продуть количество воздуха, достаточное для снятия примерно 5 кВт тепла (одного «среднестатистического» серверного шкафа). Если сервер выделяет 30 кВт, значит ему нужно отдать 6 плиток.


Защита от пыли






Заготовка воздуха

В посте про строительство этого ЦОДа спрашивали про защиту от пыли. Вообще, вещь достаточно простая, но расскажу детальнее. Нужно несколько операций:



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

  • Во-вторых, когда пыли внутри уже нет, важно не пускать её больше в ЦОД. Фильтрацию воздуха внутри машзалов обеспечивают фильтры фанкойлов EU4. То есть снаружи пыль может попасть только с посетителями.

  • В-третьих, любая пыль, пришедшая в ЦОД вместе с гостями, фильтруется теми же фильтрами, поскольку воздух внутри машзалов циркулирует фактически в замкнутом объеме с огромной кратностью.

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


Сертификация




Если коротко, то есть два подхода к сертификации – «стройте как мы сказали и всё будет ОК» — по TIA и «стройте по требованиям, и мы проверим объект» по UI. Мы сертифицировали по второй методологии, то есть прогоняли по ЦОДу фактические тесты, что довольно-таки редко в России. Список сертифицированных по TIER-III ЦОДов можно посмотреть вот здесь: uptimeinstitute.com/TierCertification/certMaps.php.

Разницу про подходы сертификации – вот здесь habrahabr.ru/company/croc/blog/157099/.



Различия между уровнями TIER I – TIER IV


TIER-III по Uptime предполагает параллельное обслуживание, когда регламентные работы и аварии не вырубают ЦОД и не снижают его выходные параметры.


Делалось это так: сначала Uptime получает проектные документы на английском. Они выдают рекомендации, потом если всё хорошо — они выдают сертификат на проект. Специалисты ATD (специалисты сертифицированные UI) могут очень помочь на этой стадии, плюс они гарантируют соответствие проекта требованиям института. Это сертификация бумаг, то есть проекта.


Затем уже куда сложнее сертифицировать построенный ЦОД, чтобы получить сертификацию объекта. После утверждения проекта и строительства парни из UI приезжают на место. У нас они пробыли 4 дня, провели комплексные испытания с имитацией кучи отказов и имитацией регламентного обслуживания. Залог успеха — полное соответствие ЦОД проекту, плюс опыт работы команды обслуживания. Если вы до этого не проводили «учебных тревог» — высок шанс не пройти проверку. Для подготовки программ обучения и персонала можно опять же привлечь ATD, если нужна помощь.


Вообще, при проектировании и строительстве ЦОДа повышенной ответственности очень важно иметь лучших специалистов в каждой сфере. Как правило, сейчас это инженеры советской школы, крайне глубоко знающие предмет и имеющие огромную практику. Подрастает и новое поколение, благо IT в СНГ развивается довольно бурно. Ещё в проектной команде нужен человек от бизнеса, который обеспечивает соответствие целей проекта целям бизнеса. Он же поможет привлечь лучшие ресурсы в случае необходимости.


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


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


Вот и всё. Больше картинок есть вот здесь в фотоэскурсии. ТТХ объекта есть на www.croc.ru/dc.


Сразу частые вопросы: окупаемость объектов такого класса около 10 лет; пожаротушение – газ, вытесняющий кислород; находится в Москве в районе Авиамоторной на территории завода «Компрессор»; проект и работы отечественные; входных векторов питания 3 – два от ТЭЦ и ДГУ, поэтому можно жестко тестировать с одним отключенным; с яблоком или мороженым в машинный зал нельзя.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Какой PHP-фреймворк вы используете?


сегодня в 08:10


Два года назад zizop задавал аналогичный вопрос. Любопытно сравнить, насколько изменился расклад сил.



Developers, stick with Russians – work in London



Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


[Перевод] Разработка web API

Интро




Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.


Собираем API-интерфейсы, которые понравятся другим разработчикам




Понятные URL для вызовов API



Первый принцип хорошего REST-дизайна — делать вещи понято и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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



/dogs для работы со списком собак

/dogs/12345 для работы с отдельной собакой





Существительные — это хорошо, а глаголы — плохо



Держите глаголы как можно дальше от базовых URL сущностей вашего API. Многие разработчки используют глаголы для описания объектов. Ясное дело, что в работе часто приходится моделировать сложные сущности. И эти сущности взаимодействуют между собой. Но при попытке ввести глаголы для моделирования сущностей и их связей, мы, скорее всего, получим большое количество труднозапоминаемых и непонятных вызовов:


/getAllDogs

/getAllLeashedDogs

/getDog

/newDog

/saveDog





Видите эти вызовы? Это ужас.
Вместо глаголов — HTTP



Мы только что описали собак с помощью двух базовых URL адресов с существительными. Теперь нам нужно работать с созданными сущностями. Чаще всего требуются операции чтения, создания, редактирования и удаления (CRUD — Create — Read — Update — Delete). Для этого нам прекрасно подойдут HTTP-методы GET, POST, PUT и DELETE.


POST /dogs — создать новую собаку

GET /dogs — получить список собак

PUT /dogs — редактирование всех собак сразу

DELETE /dogs — удаление всех собак


POST /dogs/12345 — вернуть ошибку (собака 12345 уже создана)

GET /dogs/12345 — показать информацию о собаке

PUT /dogs/12345 — редактировать собаку 12345

DELETE /dogs/12345 — удалить





Базовые URL выглядят просто, глаголы не используются, все интуитивно и понятно. Красота!
Множественное число



Хорошо использовать для описания бызовых URL существительные во множественном числе. Хуже — в единственном числе. Плохо — смешивать адреса с существительными в единственном и множественном числе.


/checkins у Foursquare

/deals y GroupOn

/Product y Zappos





Конкретные имена лучше абстрактных



Абстрактные названия — это часто считается крутым у архитекторов API. И это совсем не круто для тех, кто потом с этим API будет работать.

/blogs, /videos, /news, /articels — это выглядит очевидным. А вот /items и /assets — нет.
Связи



Одни ресурсы всегдя связаны с другими ресурсами. Если ли очевидный и простой способ показать эти связи через API. При этом помня о нашем разделении на существительные и глаголы?


GET /owners/5678/dogs

POST /owners/5678/dogs





Мы только что представили связь двух ресурсов в простом виде. Метод GET в этом случае вернет нам список собак владельца 5678, а метод POST — добавит владельцу 5678 еще одну собаку.

Связи очень удобно представлять в виде /ресурс/идентификатор/ресурс.
Сложные вещи нужно прятать за знаком «?»



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


GET /dogs?color=red&state=running&location=park





А что насчет ошибок?



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


Facebook

HTTP Status Code: 200

{"type" : "OauthException", "message":"(#803) Some of the aliases you requested do not exist: foo.bar"}





Не важно, как выполнится запрос — Facebook всегда вернет нам код 200 OK.


Twilio

HTTP Status Code: 401

{"status" : "401", "message":"Authenticate","code": 20003, "more info": "http://www.twilio.com/docs/errors/20003"}





Twilio проделали хорошую работу и для каждой ошибки в API подобрали адекватный код ошибки HTTP. Как и Facebook, ребята предоставляют информацию об ошибке еще и в теле ответа. И, что самое прикольное, они дают ссылку на документацию по проблеме.


SimpleGeo

HTTP Status Code: 401

{"code" : 401, "message": "Authentication Required"}





SimpleGeo дают сообщение об ошибке в коде HTTP и снабжают его небольшим пояснением в теле ответа.
Используйте коды ответов HTTP



Смело берите HTTP коды ответов и сопоставляйте с ответами вашего API. Всего в частом употреблении находится около 70-ти кодов. Мало кто из разработчиков помнит их все, так что из этих 70-ти лучше взять примерно 10. Кстати, так поступает большая часть провайдеров API.


Google GData

200 201 304 400 401 403 404 409 410 500






Netflix

200 201 304 400 401 403 404 412 500






Digg

200 400 401 403 404 410 500 503





Какие коды ошибок HTTP стоит использовать?



Возможно только 3 варианта ответов API


  1. Запрос прошел успешно

  2. На вход были переданы неправильные данные — клиентская ошибка

  3. Произошла ошибка при обработке данных — серверная ошибка




Так что можно взять за основу 3 кода ответов:


  1. 200 OK

  2. 400 Bad Request (некорректный запрос)

  3. 500 Internal server error (внутренняя ошибка сервера)




Если 3-х кодов вам недостаточно — возьмите еще 5:


  1. 201 Created (Запись создана)

  2. 304 Not Modified (Данные не изменились)

  3. 404 Not Found (Данные не найдены)

  4. 401 Unauthorized (Неаторизованный доступ)

  5. 403 Forbidden (Доступ запрещен)




Лучше всего не следовать этой практике слепо. Оценивайте пользу от использования HTTP кодов ответов

в каждом конкретном случае. Скорее всего, использование кодов ответов не везде будет оправданным и уместным. Например, если вы пишете бэкенд для небольшого веб-приложения — то легко можно ограничиться кодами ошибок в теле ответа. А еще стандартый ответ 200 OK позволит создать два механимза обработки ошибок: для ошибок сервера и для ошибок самого API. В общем — думайте, взвешивайте. А потом принимайте решение.

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


Никогда не выпускайте API без указания версии




Twilio /2010-04-01/Accounts

salesforce.com /services/data/v20.0/sobjects/Account

Facebook ?v=1.0





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

Salesforce.com вставляет v20.0 в середину адреса API запроса. И это очень хороший подход. Но не стоит использовать точку в нумерации версии — это провоцирует излишне частые изменения в интерфейсе API. Можно сколь угодно часто менять логику работы внутри API, но вот сами интерфейсы должны меняться максимально редко. Так что лучше обойтись без точки и не искушать себя.


Facebook тоже использует нумерацию версий в запросе, но прячет её в параметры запроса. И этот подход плох тем, что после очередного внедрения новой версии API все приложения, не передающие версию в запросе, начинают глючить.


Как реализовать версии в API?

Используйте префикс v, целые числа и располагайте номер версии в левой части адреса. Например, /v1/dogs.

Держите в рабочем виде как минимум одну предыдущую версию


Еще можно указывать версию в заголовках ответа сервера. Это может давать некоторые дополнительные возможности при работе с API. Но если вы используете множество разных версий и требуете обязательно указывать их в заголовках — это симптом большой проблемы.


Частичный ответ



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


Linkedin /people: (id, first-name, last-name, industry)

Facebook /joe.smith/friends?fields=id,name,picture

Google ?fields=title, media:group(media:thumbnail)





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



Отдавать все записи по первому же запросу — очень плохая идея. Поэтому вы должны обязательно предусмотреть паджинацию. Давайте посмотрим, как в популярных API можно вытащить записи с 50 по 75.


Facebook: смещение 50 и лимит 25

Twitter: страница 3 и 25 записей на страницу

Linkedin: с 50-й записи прочитать 25





Мы рекомендуем использовать лимит и смещение. Этот подход более интуитивен.


/dogs?limit=25&offset=50





Еще стоит приложить к каждому ответу мета-информацию: текущая страница, сколько всего записей доступно.

Предусмотрите значения по умолчанию: если пользователь не передал в запросе параметры паджинации, считайте лимит равным 10 и смещение — равным 0 (вывести первые 10 записей).


А что насчет действий?



Не все API-ресуры являются записями, которые можно читать, редактировать и удалять. Бывают и API-действия. Переводы, вычисления, конвертации — все это действия.

Лучше всего для таких запросов использовать глаголы, а не существительные.



/convert?from=EUR&to=USD&amount=100





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



Здорово поддерживать несколько форматов ответа.


Google ?alt=json

Foursquare /venue.json

Digg ?type=json





Кстати, Digg позволяет установить формат ответа и через HTTP-заголовок Accept.

Мы рекомендуем подход Foursquare.



/dogs.json

/dogs/1234.json





Еще можно предусмотреть ответы API не только в разных форматах, но и ответы для разных типов клиентов. Например, можно сделать API, способное работать одновременно с iOS-приложением и фронт-эндом веб-приложения. Это может выглядеть так: /dogs.ios и /dogs.web.
Формат по умолчанию



JSON — пожалуй, лучший формат по умолчанию. Он менее многословен, чем XML. Его поддерживают все популярные языки. Его можно сразу же использовать на фронт-энде веб-приложения.
Названия атрибутов



Атрибуты можно называть разными способами.


Twitter created_at

Bing DateTime

Foursquare createdAt





Существует много конвенций именования переменных. Нам, как спецам по Ruby on Rails, конвенция Twitter близка по духу. Но лучшим подходом мы считаем подход Foursquare: — camelCase (переменные с маленькой буквы, классы — с большой). Такой способ именования наиболее симпатичен для подачи данных в JSON: данные выглядят похоже на JavaScript. Что, в общем, логично для JSON.

Хоть автор и советует почаще использовать camelCase, лучше все же подумать о клиенте и потом уже принимать решение. Например, с вашим API может общаться программа, написанная на C, а ей лучше использовать несколько_другую_конвенцию.


Поиск



Глобальный поиск оформить просто:


/search?q=search+word





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


/owners/5678/dogs?q=red





А чтобы представлять данные в разных форматах, мы вспомним о расширениях:


/search.xml?q=search+word



Соберите все API вызовы на одном домене



Facebook предоставляет два домена.


api.facebook.com этот адрес появился первым

graph.facebook.com этот адрес ввели после внедрения глобального графа





Foursquare ограничились одним адресом


api.foursquare.com





Twitter завели 3 адреса, 2 из которых ориентированы на посты и поиск


stream.twitter.com

api.twitter.com

search.twitter.com





Легко догадаться, как Facebook и Twitter завели себе по несколько адресов: проще направлять запросы в разные кластеры через DNS, чем через логику. Но мы делаем приятный API для разработчиков, поэтому опять выберем подход Foursquare.

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


Делайте редиректы



Если кто-то обращается к вашему API-домену и не передает никаких параметров — смело делайте редирект на домен с документацией для разработчиков. Заведите несколько интуитивно понятных доменов для документации и делайте редирект на основной домен разработчиков.


api.* -> developers.*

dev.* -> developers.*

developer.* -> developers.*



Коды HTTP ответов и исключения на клиенте



Как мы уже говорили ранее, лучше всего отправлять код ошибки не только в теле ответа API, но и в HTTP коде ответа. Но как быть, если клиент выбрасывает исключение при получении любого кода HTTP, отличного от 200? Для таких случаев ребята из Twitter предусмотрели блестящее и простое решение — добавлять параметр к запросу.


/public_timelines.json?suppress_response_code=true





В результате ошибки будут приходить с кодом 200.

Предусмотрите в своем API параметр suppress_response_codes и сделайте его равным true по умолчанию.
А что если клиент поддерживает ограниченный набор HTTP методов?



В таком случае нужно эмулировать полноценный REST API с помощью GET-параметров.


чтение /dogs

создание /dogs?method=post

редактирование /dogs/1234?method=put

удаление /dogs/1234?method=delete





Будьте аккуратны с таким подходом! Если вы будете неаккуратно обращаться с такими ссылками и не обеспечите им должной безопасности, боты (вроде поискового робота Google) могут вызывать такие ссылки. И вы получите бесконечно создающиеся и удаляющиеся записи при каждом заходе бота.
Авторизация



Этот вопрос сложный, и мы с моими коллегами никогда не можем прийти к согласию быстро. Давайте посмотрим, что делают ведущие игроки.


PayPal Permissions Service API

Facebook OAuth 2.0

Twitter 1.0a





Обратите внимание на то, что PayPal реализовали свою систему авторизации еще до того, как был изобретен OAuth.

Если вам требуется авторизация пользователей через сторонние приложения — только OAuth. И ни в коем случае не делайте что-то вроде OAuth, но «немного другое».


«Болтливые» API



«Болтливые» — это значит, что для выполнения популярных операций приходится выполнять 3-4 вызовоа API подряд. Это плохо.

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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Что такое ВУЗ и чего от него ждать

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

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

Я сейчас заканчиваю четвертый курс в одном из Одесских технических вузов, параллельно с этим у меня уже набегает четвертый год стажа работы web-разработчиком. Я работал на фрилансе, делая убогие сайты на joomla, позже, работая в аутсорс компании дорос до свободного оперирования несколькими фреймворками, до хайлоадов и небольшой работой тимлидом первым помощником тимлида в становлении команды. Сейчас у меня свой, большой проект и небольшой магазин техники. Я, оглядываясь на мой студенческий и рабочий опыт, могу утвердить, что я понимаю о чем говорю.



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



Я с таким же успехом мог пойти работать и вечером изучать то, что мне нужно.





Если немного глубже попытаться понять эту мысль, то всем сразу раскроется суть высших учебных заведений. Я хочу сказать, что ни один ВУЗ в мире(!!!) не даст Вам никаких знаний. Нельзя сидеть и ждать, пока знания волшебным образом проникнут к Вам в голову, только от того, что вы будете находиться в стенах здания с соответствующей табличкой. Даже находясь в MIT необходимо очень много, самостоятельно, работать над собой. Если студент сам не будет лопатить много документации — то он этому и не научиться, а на сегодняшний день чтение документации занимает 50-60% рабочего времени программиста. Решая задачи более высокого уровня, чем уровень умения — человек развивается. С таким подходом мне удалось за неделю добиться от человека, который никогда в глаза не видел web-разработку, очень, на мой взгляд больших успехов в освоении git и фреймворка CodeIgniter. Привет Виталик! :) Результат — отличный каталог товаров с бесконечным уровнем вложений категорий. Да, не фокус, но от новичка большего ждать не требуется. (забыл сказать, что в этом году я, с моим компаньоном уже брали к себе на преддипломную практику студентов нашего ВУЗа).

Нам, на первом курсе, прямо на первой паре, декан сказал следующие слова:



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





Самая большая проблема, что никто этого до сих пор не понял. И на мой вопрос к преподавателю по операционным системам: «А будем ли мы программировать под *nix» — я увидел очень грустный взгляд и услышал фразу: «если бы, хотя бы 10% студентов этим интересовались и смогли бы попробовать осилить...»

Давайте вернемся к теме о преподавателях.

Как я говорил раньше, я долго негодовал, по поводу бумажек в руках преподавателя, по поводу некомпетентности оных, тем более мне было с чем сравнивать, за стенами ВУЗа, в офисе, у меня были наставники — гуру проектирования хайлоад систем. Когда я подумал о том, что не так — я понял. Преподаватель — это преподаватель, человек занятый воспитательной работой с шумной аудиторией, принятием экзаменов, выделением времени на пересдачи и защиты курсаков. Физически не возможно уловить все нововведения новой iOS SDK при такой жизни. По настоящему компетентные люди работают в офисах больших компаний и если, не дай бог, они все перейдут на темную сторону преподавания, то они через пол года потеряют свою компетентность.

По поводу бумажек я скажу: нельзя инженеру все знать наизусть, всегда есть справочники и литература, к примеру я запомнил, что в PHP функция strpos() пишется именно так, а не str_pos() только через год, после работы разработчиком и сейчас, некоторые решения я не смогу вспомнить на ходу, полезу в старый код или поищу на базах снипеттов.


Проблему с требованиями я решил еще во второй половине второго курса. Я просто их начал выполнять, я научился, получая на парах информацию об арифметике, дома решать дифференциальные уравнения. (Жаль не могу найти иллюстрацию, хорошая была, канула в лету). Тем более в таком ритме, что надо завтра показать что то работающие, при этом сегодня ты совсем не разбираешься в этом — придеться жить еще несколько лет, после окончания ВУЗа и на работе никаких поблажек не будет, ибо там крутятся деньги.


Суть.




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


Решили провести опрос среди студентов разных институтов — за сколько

те сдадут китайский язык. Подходя к физтеху:

— За сколько китайский сдашь?

— Ну, месяца за два.

Приходят в МГУ:

— За сколько китайский сдашь?

— Ну, где-то за месяц.

Приходят в МИФИ:

— За сколько китайский сдашь?

— Методичка есть?

— Есть!

— Ну сейчас докурю и пошли сдавать....



(спасибо за правку от ironsnake)

Как следствие, нужно уметь правильно расставлять приоритеты, понимать что тебе нужно и получать только то, что тебе нужно, остальной шлак (типа «создания почтового ящика на yandex.ru», будете смеяться, но у нас была такая лабораторная работа на первом курсе) отсеивать или отсиживать.

Эпилог




Я не пытаюсь оправдать преподавателей — шарлатанов (привет, мой зав. кафедры! :) (это не про него, это он так называет всех преподавателей на нашей кафедре) ). С такими преподавателями всегда можно бороться интеллектом — это не проблема.

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

P.S. Прошу прощения, за размещение в хабы «программирование». Добавить в хаб «учебный процесс в it» — карма не позволяет, никак руки не доходят решить проблему. Тем не менее, многие проблемы по части программирования берут свою корни еще в ВУЗах.


Спасибо за внимание!


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


четверг, 13 июня 2013 г.

Как стать хорошим менеджером

Думаю, многие согласятся с тем, что у нас очень много хороших IT специалистов. И даже наше образование, а также политические, экономические и другие факторы не сильно могут помешать стать хорошим IT специалистом при наличии желания. Но вот с менеджерами в сфере IT не всё так хорошо…

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


Образование




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

Эти предметы номинально преподают в технических университетах, но их количество и качество стремятся к нулю. Таким образом, университетское образование никак не решает вопрос воспитания IT менеджеров.


Так где же брать IT менеджеров? Из смежных областей менеджеров не возьмешь — у них банально не хватит квалификации.


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


Мышление




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

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


И вот тут кроется одна из главных проблем. Средняя продолжительность работы IT специалиста в одной компании — 1.5-2 года. Поэтому компании могут быть практически на 100% уверены, что разработчик не будет работать в их компании, когда закончится процесс его обучения. Таким образом, нет смысла и начинать его учить…


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


Также нужно помнить, что хорошим менеджером может стать далеко не каждый технарь. Схема «сегодня — лучший разработчик, завтра — хороший менеджер» не работает. Можно потерять хорошего разработчика и получить плохого менеджера. Экономический эффект от этого даже не стоит начинать считать.


Лучший момент для начала трансформации разработчика в менеджера — middle уровень. В это время нужно начинать читать специализированную литературу (а не только литературу по технологиям). Лучше всего начать с Peopleware Тимоти Лестера и «Джоэл о программировании» Джоэла Спольски. А дальше по списку.


Практика




Работа менеджера строится на управлении людьми. Проблема в следующем: чтобы стать хорошим IT специалистом, нужен лишь компьютер, интернет и желание; хорошим менеджером без практики стать вряд ли получится.

Ответственность




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

Еще раз повторюсь: за все косяки в команде должен отвечать менеджер.


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


Пример из жизни: как-то задал вопрос своему менеджеру, кто возьмет на себя ответственность за нереальную оценку, отсутствие квалифицированных кадров и внедренную методологию управления под названием scrumно. На что получил удивленный ответ: все. При персональной ответственности за свою работу ничего подобного бы ни было. Думаю, не нужно говорить, что проект с треском провалился, и никто при этом не понёс персональное наказание.


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


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


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


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


К тому же ситуация, когда разработчик зарабатывает больше своего менеджера, — не редкость в IT компаниях, хотя в других сферах такое случается крайне редко. Этим также можно объяснить нежелание многих технарей превращаться в менеджеров.


Вместо заключения




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

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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


LIFT — коворкинг в глубинке: инструкция по применению

Всем привет! В прошлой своей статье я рассказывал про Астраханский IT-парк и то, как развивается IT-сфера в нашем городе. Тогда я пообещал, что следующий мой пост будет посвящен бизнес-инкубатору и коворкингу «LIFT». Ну, что ж, обещал, значит надо писать, тем более, что на носу открытие. В статье пришлось использовать фотографии с девушками, но это не специально. Кто хочет прочитать про опыт в создании коворкинга, узнать о возникших проблемах и о том, что в итоге вышло, добро пожаловать под кат.



Ты помнишь, как все начиналось?




Все началось холодной и дождливой осенью 2012 года. В то время я работал проектным менеджером в крупной IT-компании и прошел ровно год с той поры, когда я решил забросить свою веб-студию и вернулся к «работе на дядю». Сам я по образованию программист и прошел по цепочке «программист ->тимлид -> проектный менеджер ->менеджер среднего звена -> собственный бизнес». В компании я занимался проектами по разработке и внедрению ПО и заведовал развитием новых направлений и продуктов (дальше буду употреблять к месту и не к месту избитый термин «стартап», потому что так короче).



Russian Startup Tour (апрель 2013)



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

Решили начать с конкурса стартапов «Startup Search», который был проведен в октябре 2012 года. Конкурс был очень важен в плане того, что, к моему удивлению, нашлись проекты и команды, о которых я и не слышал никогда, но, с другой стороны, стоящих проектов оказалось крайне мало. Основная причина этого – отсутствие вменяемой экосистемы в нашем городе (да и не только в нашем, это проблема любого города-миниполиса). Профессиональных сообществ нет, тусовки нет, конференций и образовалок толковых нет, хороших работодателей по пальцам руки пересчитать можно. Конечно, новостью это не стало, и уже давно в голове среди тараканов, борющихся со штормовым ветром, витала идея создания профессионального сообщества и площадки, где оно бы могло жить и развиваться.



Так появился проект, позже названный «LIFT», – бизнес-инкубатор и коворкинг, который станет столпом надежды IT в Астрахани, а позже будет масштабирован на другие регионы. А после разговора с Дэвидом Уикли (DavidWeekly) и Тимом Сиасом (TimSears) из HackerDojo (о нем уже недавно писали тут), их положительного опыта и работы Зоны Действия (о нём тут), стало понятно, как все это дело должно выглядеть и работать. Как и в любом другом проекте есть региональные особенности, которые и побудили меня написать этот пост.


Первым делом самолеты




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



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

С проектами, как я уже говорил, было тоже довольно грустно (3-4 проекта, большей частью студенты без денег и команды). Мода на стартапы в наш город ещё не пришла (что может быть и к лучшему). Студенческие стартапы у нас оказалось явлением настолько же редким, как и появление Несси на глаза широкой публики.



Санузлу нужна твоя одежда и мотоцикл.



В общем, с клиентами, которые бы окупали площадку и её использовали, все было совсем туго. Поскольку проект коммерческий и без государственных вложений, то стало грустновато. Нет стартапов и сообщества, потому что нет экосистемы, а экосистемы нет, потому что нет стартапов и сообщества. Замкнутый круг, который надо было разрывать. Для этого пришлось плыть против течения и нести дополнительные расходы, но от идеи отказываться не хотелось. Если не мы, то кто?
Площадка



Тут было попроще, потому что уже стартовал проект Астраханского IT-парка и «LIFT» идеально вписывался в его идеологию. Поэтому удалось получить помещение в 350 кв. м. на первом этаже, раньше на этом месте был мебельный магазин, оставивший после себя большую квадратную площадь, с довольно высокими потолками, которую с минимальными вложениями можно было превратить в то, что душе хотелось.

Быстренько подготовили план будущих помещений: рабочей зоны, конференц-зала, переговорной комнаты, кухни, туалетов, зоны отдыха.



Гамак и барабашки в зоне отдыха. Тут действительно иногда спят.



В рабочей зоне умещается 37 стационарных мест примерно на 180 кв. м. Вместимость конференц-зала – около 60 человек, от рабочей зоны он должен быть отделен ширмой, чтобы можно было проводить там мероприятия в рабочее время. Из расчета, что здесь будут проходить мероприятия под 150 человек, было решено сделать сразу 3 туалета (во время тусовок сисадминов, которые проходят с пивом, туалеты пользуются большой популярностью).

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




Комната, где ведутся важные переговоры.



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

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




Конференц-зал со стеной под мел.



Естественно, по всей территории работает Wi-Fi, все как положено: Интернет-канал 20 Мбит/с резервирование, класс N, роуминг и все дела. Максимально выдерживал одновременное подключение 140 пользователей. По колоннам в центре зала идет проводной интернет для десктопов.

Дальше начался долгий процесс дизайна, который отнял много времени и сил, в результате было отвергнуто несколько вариантов, в ходе проектирования меняли дизайнера и т.п. Конечный вариант получился хорошим, но мой совет – не уделяйте так много внимания внешнему виду. Сосредоточьтесь на удобстве и эргономике, красоту оставьте на потом. Если бы мы увидели HackerDojo (не тот, который сейчас, а тот который был) не в феврале, а раньше, то проблему дизайна мы бы решили меньшими силами. Сейчас я понимаю, что на косметический ремонт можно было забить, атмосферу создают мелочи и люди, которые в дизайне не учитываются.




План помещений



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

Финансы




Пожалуй, дошли до самого интересного места. Пока рано говорить о доходах, потому что площадку только запустили. Сейчас она генерирует около 200 000 рублей расходов ежемесячно, без учета ЗП, поскольку пока наемных работников нет.



Рабочая зона и мотивирующие плакаты.



Ценовая политика у нас такая: 3000 рублей в месяц за плавающее рабочее место, 5000 рублей – за фиксированное. Плюс есть часовые тарифы, можно снять на время переговорку или конференц-зал. Несложно подсчитать, что даже при 100% загрузке коворкинга постоянными резидентами нельзя окупить даже постоянные издержки, не говоря уже о наемных сотрудниках и доходах.

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


Третья статья доходов – спонсорство и партнерство. Тут все неочевидно, поскольку пока практики такой не имеем. Уже есть партнеры, правда, их поддержка не денежная, но вдруг. Исключать этого не могу, если у кого уже есть такой опыт – скажите.

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


Продвижение



Сейчас целенаправленное продвижение идет по трем каналам: сарафанное радио, мероприятия на площадке, самостоятельное продвижение в соцсетях. Проведение разноплановых мероприятий – наиболее действенный инструмент, поскольку автоматически приводит за собой нужные СМИ, подтягивает аудиторию из соцсетей и запускает сарафанное радио.



Одна из традиционных игротек в выходные.



Важно проводить на площадке не только тематические мероприятия. Например, почти каждую неделю у нас на площадке проходят игротеки, интеллектуальные игры клуба «Что? Где? Когда?», был опыт проведения благотворительных мероприятий. В итоге, если о том, что такое «LIFT», раньше никто не знал, то сейчас среди целевой аудитории есть нужный нам информационный шум, который в результате приводит к нам именно тех, кого мы ищем.
Что есть сейчас и чего добились?



Как ни странно, официальный запуск у нас только 14 июня (если успели прочитать до открытия, то приглашаю в 16:00!). На данный момент у нас в коворкинге ежедневно работает около десятка человек, в инкубаторе находится 4 молодых стартапа (сейчас процедуру отбора проходят ещё 3), в неделю стабильно проходит 3-4 мероприятия. После открытия пускаемся в активную фазу работы и планируем к концу июля полностью забить коворкинг, довести количество инкубируемых проектов до 10, запустить несколько образовательных программ. 5-7 июля проводим хакатон, 29 июля запускаем школу для стартапов, в конце июля – регулярные четырехнедельные школы для программистов и минишколы по программированию по конкретным тематикам.

У нас уже проходили экспресс-школа для молодых программистов ЮФО «IT-Start», зональный этап «Microsoft Imagine Cup», роуд-шоу институтов развития «RussianStartupTour» (кстати, именно наш резидент «Bravo Motors» стал победителем «StartupVillage» с проектом «e-Trike») и многое другое.




Кусочек кухни. Практически вся мебель – из Икеи.



Количество партнеров и помогающих нам друзей достигло полусотни, совсем недавно стали партнерами Microsoft (по программе BizSpark и образовательным программам), знакомы практически со всеми крупными венчурными фондами, работающими в России, а в нашей сети экспертов – специалисты со всего мира, начиная от Казахстана и заканчивая Долиной. Сейчас активно работаем над образовательными и акселерационными программами и ищем менторов для проектов в инкубаторе, поэтому, если можете помочь – милости просим.
Что дальше?



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

P.S. Надеюсь, что было интересно. Как всегда, готов ответить на вопросы в комментариях, будет интересно получить обратку. Следующую статью напишу, когда все заработает в полную силу, может быть, расскажу о проектах. А что хотели бы услышать вы?


P.P.S. В статье использованы фотографии проекта «AstFutur», Ивана Ротанова, Романа Шейна и других посетителей нашей площадки, за что им огромная благодарность.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


[Из песочницы] Окрашивание изображений



Здравствуй, Хабрахабр. Сегодня мы будем раскрашивать.

Что здесь будет? Будет поиск цветного изображения со схожими цветами по черно-белому и метод переноса цвета с первого на второе.



Поиск цветного изображения




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

Сигнатура — это 128 чисел с плавающей запятой, они получаются из гистограммы канала l (яркость) изображения (из цветовой модели lab), нормализованной к единице, то есть сумма всех 128 чисел равна единице (нормализация нужна для того, чтобы убрать влияние размера изображения на сигнатуру). Схематично получение сигнатуры изображения выглядит так:


Подобный подход описан в [2], там есть и другие варианты сигнатур и экспериментальные результаты. Теперь у каждого цветного изображения есть сигнатура, и у черно-белого она тоже есть, как мы выберем изображение? Вычислим корреляцию между сигнатурой нашего бесцветного подопытного и цветных кандидатов, по наибольшему значению получим победителя. Корреляция, кстати, вычисляется вот так:





Здесь H1 и H2 — сигнатуры, N=128 — число элементов сигнатуры. Если d=1, то максимальное совпадение, -1 – максимальное различие, 0 – нет корреляции.

На этом этапе у нас уже есть черно-белое изображение и изображение-источник цвета, назовем его так. На первой картинке это левое и правое изображения, осталось получить центральное.


Перенос цвета с цветного на черно-белое




Этапы переноса цвета следующие:

1. Накладываем на изображение-источник цвета сетку 15х15, в каждой ячейке берем случайный пиксель (это называется jittered sampling)

2. Рассматриваем окрестность это пикселя в размере 25х25, вычисляем математическое ожидание и дисперсию.

После первых двух шагов мы получаем с цветного изображения 225 образцов цвета, каждый из которых характеризуется следующим: двумя значениями каналов a и b; мат. ожиданием и дисперсией.

15х15 и 25х25 получены в ходе экспериментов.

3. Попиксельно обходим наше черно-белое изображение, вычисляем дисперсию и мат. ожидание, сравниваем с образцами, с наиболее подходящего образца переносим значения цветовых каналов a и b.

Этот метод придумал Welsh с товарищами, подробнее можно почитать у него [1].


В результате этих нехитрых манипуляций получаются вполне себе цветные картинки:



Ну и как же без рыжего кота:




Выводы




Ну, достоинства тут очевидны, руками ничего не делаем, все само красиво происходит, а недостатки? Для изображений, где основных тонов не два-три, а много больше, результаты могут получиться сильно неадекватные, устраняется это очень просто на словах и очень сложно на деле: применение распознавания, например, при использовании метода SURF и контурного анализа для поиска машинки, можно вместо:


получить гораздо более правдоподобную картину:



но это уже совсем другая история.


P.S.




Я буду крайне признателен за альтернативные подходы к окрашиванию в комментариях, хотя бы на уровне идей.

Использованные источники:

1 Welsh, T., Transferring color to greyscale images

2 Vieira, L. F. M. at al. Fully automatic coloring of grayscale images


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


[Перевод] Хакеры против Правительства: почему гики разглашают информацию?

Когда The Guardian представила свой профиль Эдварда Сноудена, в нем была фотография 29-летнего работника со своим ноутбуком. На его крышке были наклейки Electronic Frontier Foundation, группы защищающий цифровые гражданские права, и Tor, сети, которая позволяет людям анонимно исследовать Интернет.

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


Этими же чертами обладает и Брэдли Мэннинг, молодой солдат, который обвиняется в утечке секретных документов в пользу WikiLeaks. Они так же описывают и основателя WikiLeaks Джулиана Ассанджа. И это не случайно.


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


Наш Дилан Мэтьюс недавно написал о Джейсоне Тригге, программисте с Уолл-Стрит, который решил, что он просто морально обязан отдавать половину своей зарплаты на благотворительность.


В 1980 программист MIT по имени Ричард Столлман решил, что аморально использовать или распространять проприетарный софт. В результате, три десятилетия спустя, существует современное движение бесплатного ПО.


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


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


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


Хакеры, как правило, ожесточенно защищают гражданские свободы. Социальный новостной сайт Hacker News переполнен новостями об АНБ с самого первого момента, как The Guardian опубликовала первую новость на прошлой неделе, и комментаторы в подавляющем большинстве поддерживают Сноудена.


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


Для того, чтобы получить некоторое представление о том, почему так много хакеров участвуют в раскрытии секретной информации или страстно поддерживают тех, кто это делает, я позвонил Якову Аппельбауму. Он разработал проект Tor и долгое время поддерживает WikiLeaks.


Он не слишком поддержал мои тезисы. «Это речь о храбрости, а не о том, как использовать Linux», — говорит он. «Мужество, моральные и этические аспекты гораздо важнее технологии».


«Нравственный человек попал бы в беду, следуя приказам», — говорит Яков. «В длинном хвосте истории просто следовать приказам ошибочно. Это ключевая вещь, которая действительно имеет значение»,


Конечно, объяснение Аппельбаума и мое не являются взаимоисключающими. Столлман, Шварц и Тригг — каждый выказывает свой вид мужества в своем целеустремленном преследовании идеалов. Они сделали то, во что верили, что, по их мнению, правильно, не обращая внимания на то, как на это могут посмотреть остальные. Так что, наверное, не случайно то, что такие мужчины как они готовы рисковать всем, чтобы добиться большой прозрачности для дела государственной безопасности.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html