Андрей Николаев: Если этот документ - какой-нибудь слепой договор, то превью ему делать бессмысленно. Если же это книга или презентация, то обычно обложка или концептуальное приветствие размещается на первой странице.
Первая строчка кода гениальна. Так и просится на демотиватор какой-нибудь.
Кстати, вы забыли рассказать, в чем, собственно, проблема.
Раз уж вы в курсе, что задача решается IM.
Я бы для начала разбил задачу на независимые куски.
С порта льется поток, который надо сохранить. Обязательно. Пусть он сохраняется в файлы с именем %Y-%m-%d_%H, например. Четко и без вариантов. Данные всегда сохранены.
Данные должны попасть в базу. Нужен сервис, который определяет, есть ли файлы с именем меньше текущего часа, и пытается их отправить. Если это проходит удачно - удаляет. Варианты исполнения такого функционала выбираем на вкус и цвет.
Сергей: если у них задолженность за полгода - им только сервиса, на хрен отрубающего всю работу, для полного счастья не хватает.
Я пытаюсь представить, как выглядит ваше предложение с точки зрения клиента, который его обдумывает. Я бы - просто отказался. И даже не потому, что предполагаю динамить оплату сервиса или жду от него подлянок. Просто случаи бывают разные, и глупо совать голову в петлю без всякой на то необходимости. It smells, компрене-ву?
Вообще-то в любой версии будет работать floor( $a / $b ), зачем лишние сущности?
Вот эта "своя реализация", например, может ненароком поймать ошибку точности и выдать 0.999999999999999
Сергей: однако на практике мне схема "оплатил сервис - есть обслуживание, не оплатил - нет обслуживания" представляется более естественной, чем "не оплатил - вообще работать не сможешь".
Это нужно быть сильно недальновидным или очень доверять контрагенту, чтобы под такое подписываться. Даже предполагая всеобщую добрую волю и никаких подвохов.
Сергей: не так же.
У них есть альтернатива и есть гарантия, что завтра они не пропадут с концами.
В вашем же случае в любой момент может оказаться, что вы загремели в больничку на Самуи без интернета, а у клиента встал колом весь офис, и никто не может исправить эту ситуацию за разумные деньги.
Сергей: я, конечно, не знаю вашей ситуации. Но связываться с обслуживателем, который сразу монтирует рубильник и обещает за него дернуть, как только ему что-то не понравится, я бы не стал. Да и фактор автобуса маловат...
Сергей: просто если ваша услуга - не столько система, сколько обслуживание, имеет смысл и говорить об оплате обслуживания, а не системы. То есть отталкиваться от ваших часов возни с проблемами, а не от количества установок. Возможно, корреляция будет прямой, но контролировать время с вашей стороны куда как проще.
Вопрос в том, чем ваша "сборка" отличается от любого бесплатного дистрибутива.
Очевидно, какие бы то ни было ограничения могут быть только в рамках этих отличий.
Вот кто вам это сказал? Лично Гейтс?
Нужен вам гуй в Убунте - apt-get *-desktop, и не делайте людям голову.
Впрочем, если вы по-прежнему верите, что вам зачем-то необходимы окошки, ниже уже ответили - удаленное подключение работает без проблем.
Скорее всего, это будет быстрее, чем Шторм в виртуалке.
Не так быстро, впрочем, как при выкидывании винды из этой схемы вовсе.
GrAl: и не будет без опыта. Представьте, что ООП - единственный инструмент, который у вас есть. И все должно решаться только с его помощью. Так придет понимание, как сделать что-то удобнее с ООП, а потом - и как именно ООП позволит сделать все удобнее и проще.
Главное - быстрее перейти от "запихну процедуры в комок и назову это классом" к "вот эта часть кода пересекается с другими только вызовом нескольких методов и представляет собой абстракцию более высокого уровня, чем просто набор методов".
Не могу, правда, сказать, насколько для этого подходят именно выбранные вами языки.