У вас как-то все перепуталось. DynamoDB — это штука для больших данных/нагрузок, когда вы жертвуете гибкостью схемы ради «бесконечного» скалирования. Посмотрите стримы Rick Houlihan про применение single table design или его доклады на re:invent.
Дополню своими мыслями после 4-летнего ежедневного учета расходов:
1) Подключите СМС/пуш нотификации от банков и удаляйте их только после добавления транзакции в программу учета. Это можно делать сразу или в конце дня.
2) Поэтому расчеты наличными очень неудобны. Особенно, учет расходов членов семьи.
3) Как минимум раз в неделю полезно делать контрольную проверку сумм на всех счетах дабы избежать неприятных сюрпризов.
4) Категория Забытое/Разное очень важна. Не надо стесняться и добавлять все нестыковки туда.
5) Супер-детальные категории расходов на первом этапе больше мешают. Привычка записывать все расходы важнее. То есть категории Автомобиль будет достаточно, а отдельные категории ТО, Бензин, Штрафы уже избыточны.
6) Планирование можно начать с горизонта в 2-3 месяца. Попробуйте равномерно распределить грядущие расходы по месяцам и жестко следовать плану. «В этом месяце потрачу больше, а в следующем сэкономлю» не работает, вы забудете об этом первого числа следующего месяца.
У меня просто сложилось ощущение, что вы слишком много думаете над вещами, которые этого не стоит;) Когда я получаю прирост производительности порядка 400% от включения оптимизатора, адекватного кеширования и правильной настройки сервера, то 5-10%, которые я выиграю от скурпулезной оптимизации кода, меня все равно не спасут. Но времени я затрачу на это гораздо больше, чем на первые мероприятия.
Большинство этих оптимизаций дают на порядки меньший прирост в реальных проектах, чем оптимизация архитектуры и способ запуска проекта (кеширование, оптимизация базы, выбор более легких серверов, например, nginx). eAccelerator и иже с ним сводят к нулю влияние конструкций языка на конечное время выполнения программы. Если вы даже посмотрите на тесты, то увидите, что различия проявляются только на большом числе итераций, в реальных проектах тех же print очень немного.
В случае, если вы действительно уперлись в скорость языка, то скорее всего вы либо гугл, либо пожалели деньги на хостинг:)
Экономия на трафике — это в большинстве случаев экономия на спичках. Ключевое преимущество JSON заключается в первой букве его названия:) Это просто гибкий и, что самое главное, родной способ описания всего и вся для JavaScript.
Спасибо за информацию, узнал пару новых способов защиты для себя. Вообще, мне идея капчи уже давно кажется порочной с появлением глазоломательных картинок. По большому счету проблемы спама, автоматических регистраций и т.д. — это проблемы сервиса, а не пользователя. Забавно порой выглядит, когда в форме регистрации, которая расчитана на ускорение этой процедуры: минимум полей, приятная валидация — стоит нечитаемая капча. В итоге все прелести формы нивелируется ей, когда тратишь на прочтение капчи несколько десятков секунд, а то и несколько перезагрузок страницы в случае ошибки.
Поэтому и стараюсь в своих проектах обходиться защитами, которые скрыты от пользователя. В случае целенаправленной атаки все равно никто и ничто не спасет.
Тогда мне непонятна эта фраза «Python примерно соизмерим по скорости с Perl. Ruby 1.8 естественно проигрывает. PHP почти быстрее всех...» без контекста естественно. Каков процент таких счетных задач на скриптовых языках программирования, чтобы о быстродействии вычислений факториала, можно было судить о быстродействии всего языка?
Просто откровенно раздражают такие необъективные выводы, только зря народ неопытный баламутите.
Странный тест. Взяли вообщем-то редко используемую задачу в этих языках программирования и на ее основе делаются выводы о скорости всего языка. Например, по вашим данным Python проигрывает PHP, но я специально сравнивал их скорости на конкретной небольшой, но комплексной задаче, результат, как вы понимаете, был абсолютно противоположный.
Совмещаем 1 и 2 картинки в строке. Если зубчики на одной позиции, но в разные стороны, то они убираются. Получаем 3 картинку в строке. В последней строке ничего не убирается, поэтому 1 вариант.
Спасибо за проделанную работу. Маленькое замечание: в легенде к графикам слишком узкие полоски, поэтому цвет непонятен, и сделайте цвета поконтрастнее относительно друг друга.
Какой их процент по отношению к тем, у кого он включен? Для таких людей всегда можно поставить тег noscript. Но из-за очень маленькой группы параноиков усложнять жизнь большинству по-моему неправильно;)
По-моему, при высокой скорости печати эта программа будет только мешать. Вместо того, чтобы оттарабанить текст придется пробежаться глазами по вариантам. На днях как раз набирал текст в OpenOffice, отключил к чертям автодополнение через 2 абзаца:)
Но, правда, зачем выкидывать jQuery, если она работает и задачу решает?
1) Подключите СМС/пуш нотификации от банков и удаляйте их только после добавления транзакции в программу учета. Это можно делать сразу или в конце дня.
2) Поэтому расчеты наличными очень неудобны. Особенно, учет расходов членов семьи.
3) Как минимум раз в неделю полезно делать контрольную проверку сумм на всех счетах дабы избежать неприятных сюрпризов.
4) Категория Забытое/Разное очень важна. Не надо стесняться и добавлять все нестыковки туда.
5) Супер-детальные категории расходов на первом этапе больше мешают. Привычка записывать все расходы важнее. То есть категории Автомобиль будет достаточно, а отдельные категории ТО, Бензин, Штрафы уже избыточны.
6) Планирование можно начать с горизонта в 2-3 месяца. Попробуйте равномерно распределить грядущие расходы по месяцам и жестко следовать плану. «В этом месяце потрачу больше, а в следующем сэкономлю» не работает, вы забудете об этом первого числа следующего месяца.
В случае, если вы действительно уперлись в скорость языка, то скорее всего вы либо гугл, либо пожалели деньги на хостинг:)
Поэтому и стараюсь в своих проектах обходиться защитами, которые скрыты от пользователя. В случае целенаправленной атаки все равно никто и ничто не спасет.
Просто откровенно раздражают такие необъективные выводы, только зря народ неопытный баламутите.