А, ну тут не знаю. От среды разработки зависит. С Postgres работаю либо непосредственно в pgAdmin, либо локально любым текстовым редактором, код на plpgsql, математики мало, в основном бизнес-логика, но её очень много :)
А что посоветовать для Python'а не знаю…
Дебажить — RAISE NOTICE, RAISE EXCEPTION. Версионировать — DDL объектов в файлах. А дальше как угодно — хоть систему контроля версий.
Просто если у вас пара-тройка клиентов — ваш подход оправдан, а если много — то не очень.
А за некоторые фишки Python'а спасибо, пригодится. Я на нём мало писал, в основном простенькие скрипты (намного удобнее, а главное — быстрее, чем на bash'е)
Для начала подключимся к постгресу и получим результат запроса
Для PostgreSQL есть расширение PL/Python — Python Procedural Language, позволяет писать код на Python непосредственно в теле функций.
ИМХО хранить и сопровождать логику в объектах БД намного проще.
Это если специально готовиться к такой экспертизе. Но подавляющая часть преступников, даже пытаясь скрыть следы, элементарно оставляют отпечатки пальцев, не говоря уже о других прямых уликах. Технически грамотные люди среди них редкость, большая редкость.
Хотя сам метод спорный и сложный, но даёт пищу для фантазий :)
Могу ошибаться в названии (пусть он будет «байт»), но адресуемый размер не всегда равен 8 бит.
мега- в как «двоичная» используется исключительно с байтами. 64 килобит/с всегда означало ровно 64000 бит/с
А я разве что-то против сказал? Двоичные «мега-» как раз используются только с объёмом, и только в байтах (8-битных).
На самом деле проблем с названием применительно к железу нет. Например — «слово» (адресуемый объём памяти в процессорах/контроллерах), «семпл» (в устройствах аналого-цифровых преобразований) «бод»,«бит» в сетях и т.д.
Проблема встаёт с определением объёма информации в умах людей. Вот «файл 100 метров» — всем понятно, а 800 мегабит/мебибит — совсем нет. Какой-бы вы не были IT-профессионал, сообразить в уме будет трудно. Только из-за того, что эти названия так приелись, как килограмм и километр, и покупать картошку в фунтах нам совсем не удобно.
Однако, линуксового клиента и прямых ссылок на файлы одновременно пока ни у кого нет, кроме DB. Например для меня эти факторы решающие.
А место — хорошо конечно, когда его много, но мне и 2Гб хватает (я даже ни в каких акциях по увеличению не участвовал)
бОльшую часть этой работы создаёт неэффективный бизнес или законотворчество. А чаще наоборот — хитро продуманный, особенно там, где есть возможность заработать только лишь создавая видимость бурной деятельности.
Те задачи, которые могли бы (и хотели бы) решить пятой местных айтишников, знающих предметную область как свои пять пальцев, отдают за миллионы сторонним компаниям («сторонним» на бумаге разумеется), которые имеют лишь пафосное имя и несколько «племянничков шефа» в качестве исполнителей.
И эти задачи решаются год-другой, бумаги туда-сюда, деньги перетекают, всё крутится-вертится. На выходе имеем полное дерьмо, которое соответствует кривым ТЗ, но работать с ним совершенно невозможно.
Я до этого не видел, лень как-то было (ну в реале, на видео разумеется смотрел). А сейчас и осцилл под рукой, и ссылка на файл, и кусок провода с джеком на столе валяется…
Хуже того: контроллер скорее всего один и тот же, что у многих «китайфонов», что и у i-xxx. Ровно как gsm-модуль и многое другое. Такие вещи не делаются в подвале на коленке, а делаются огромными партиями (том же Китае) и продаются сотням компаний, как крупным брендам, так и мелким оптовикам.
А что посоветовать для Python'а не знаю…
Просто если у вас пара-тройка клиентов — ваш подход оправдан, а если много — то не очень.
А за некоторые фишки Python'а спасибо, пригодится. Я на нём мало писал, в основном простенькие скрипты (намного удобнее, а главное — быстрее, чем на bash'е)
Для PostgreSQL есть расширение PL/Python — Python Procedural Language, позволяет писать код на Python непосредственно в теле функций.
ИМХО хранить и сопровождать логику в объектах БД намного проще.
Хотя сам метод спорный и сложный, но даёт пищу для фантазий :)
мега- в как «двоичная» используется исключительно с байтами. 64 килобит/с всегда означало ровно 64000 бит/с
А я разве что-то против сказал? Двоичные «мега-» как раз используются только с объёмом, и только в байтах (8-битных).
Проблема встаёт с определением объёма информации в умах людей. Вот «файл 100 метров» — всем понятно, а 800 мегабит/мебибит — совсем нет. Какой-бы вы не были IT-профессионал, сообразить в уме будет трудно. Только из-за того, что эти названия так приелись, как килограмм и километр, и покупать картошку в фунтах нам совсем не удобно.
Вот не понимаю, неужели мелкую утилиту трудно сделать кроссплатформенной?
А место — хорошо конечно, когда его много, но мне и 2Гб хватает (я даже ни в каких акциях по увеличению не участвовал)
Те задачи, которые могли бы (и хотели бы) решить пятой местных айтишников, знающих предметную область как свои пять пальцев, отдают за миллионы сторонним компаниям («сторонним» на бумаге разумеется), которые имеют лишь пафосное имя и несколько «племянничков шефа» в качестве исполнителей.
И эти задачи решаются год-другой, бумаги туда-сюда, деньги перетекают, всё крутится-вертится. На выходе имеем полное дерьмо, которое соответствует кривым ТЗ, но работать с ним совершенно невозможно.