иного программиста хлебом не корми — дай чего-нибудь поанализировать. Вот и я набрал себе в мегафоне детализаций приблизительно за полтора месяца (по неделе каждая), и стал в них ковырять электронными таблицами. Пока особо полезных выводов не получил, но некоторая выжимка всё-таки имеется.
итак, мой тариф — Мегафон О'Лайт. Звонки по стоимости попадают в одну из двух групп. Первая включает в себя все мобильники москвы и области — и мегафоновские, и прочих операторов, их конечная цена 5 центов или 1.36 рубля. Ко второй группе относятся все остальные звонки: стационарные в москве, междугородные и международные, их цена колеблется в районе 25 центов (6.6 рублей)
оказалось, что в месяц я делаю порядка 60 звонков общей длительностью 150 минут, и трачу на это около 25 баксов. Я думал, раза в два меньше, потому что раньше клал деньги небольшими порциями по мере необходимости.
оказалось, что почти треть времени (50 минут) я говорю с кем-то за пределами области. Денег на это уходит чуть больше половины. Звонков на стационарные телефоны москвы — еще одна шестая (25 минут), что в сумме дает половину по времени и 5/6 денег.
оптимизацию расходов, очевидно, нужно начинать с межгорода. Можно звонить по инету, но страдает качество связи и комфорт — бродить с телефоном удобнее, чем сидеть на коротком поводке наушников у компа. Можно поискать оператора/тариф подешевле, но я не уверен в их существовании (народ, как у вас с ценами на межгород?).
следущий пункт в очереди на оптимизацию — городские телефоны. Говорю я с ними в три раза меньше, чем с мобильными, но стоят разговоры в пять раз больше. Тут уже должно быть реально найти более вкусную комбинацию цен на другом тарифе.
а вообще, конечно, если пытаться экономить, начинать нужно со статей расходов покрупнее — вроде квартиры и еды : )
Когда-то в детстве я видел по телику передачу «Форт Баярд». Показывали в ней, как команда из нескольких человек бегает по антуражному старому замку и выполняет разные задания. Если набирается достаточное количество очков, команда имеет бабло в конце. Оказывается, эта забава популярна в массах и сейчас, причем люди легко обходятся и без замков с тиграми. Достаточно найти в области несколько заброшенных строек или просто неиспользуемых зданий, спрятать там ключевые слова, и добавить задания в городе по вкусу. После этого десятка два команд на нескольких машинах каждая вооружаются фонариками, рациями, ноутами с инетом и прочей соответствующей атрибутикой, и начинается «Схватка».
Как раз в такой развлекухе я вчера и поучаствовал. Впрочем, роль у меня была сравнительно простая (или наоборот) — 3C: command, control, communications. Штаб, проще говоря : ) Хотя, на самом деле, я был удаленным интернет-терминалом с хорошим каналом. Интеллектуальным, надеюсь : ) В общем, сидел дома, очень много общался по телефону с командами, и отслеживал задания в инете. Интереса добавляло то, что из 9 человек в команде меня знал только один. Почти как в кино — таинственный главный % )
Интересно было бы посмотреть на результаты хороших исследований читаемости кода. Хороших — значит проведенных опытной лабораторией по юзабилити. А что касается читаемости, так тут разных направлений вагон и маленькая тележка, начиная от синтаксиса разных языков, и заканчивая стандартами оформления кода (например, лично меня бесит код почти без пробелов).
Интересно потому, что наверняка синтаксис и стандарты кодирования обычно создаются людьми, далекими от удобства использования чего-либо. По моему опыту, средний программист в этом смысле даже хуже среднего человека.
Допустим, у вас есть большой сервис c авторизацией по логину-паролю. Вы боитесь спамеров, поэтому не хотите делать регистацию просто по openid. Однако вы можете значительно облегчить жизнь своим пользователям (если, конечно, у вас нет классической жадности «юзер должен ходить только на мой сайт»). Очень просто сделать так, чтобы юзер не должен был помнить логин и пароль на ваш сайт. Пусть он подтвердит в настройках обладание каким-то openid, и после этого логинится к вам не по логину-паролю, а по указанному openid.
Проблема состояла из двух частей. Первая — это необходимость заводить новые логин-пароль на сервисе, но от этого вы и не хотели отказываться. Вторая — юзеру нужно было помнить/восстанавливать логин-пароль для пользования сайтом. Предложенный подход избавляет его от этих усилий.