Программирование, т. 5.1.

уже есть хттп, на чистом хттп можно писать отличные сервисы

нет, хотим объекты, хотим жрать говно

а еще есть tcp. и чо? какие блядь объекты, поехавший ты?

wsdl - это удобно.

Умею в UML и распределенные SOAP сервисы на RESTful облаках.

Беру 40 евро/час, в пм

уже есть хттп, на чистом хттп можно писать отличные сервисы

нет, хотим объекты, хотим жрать говно

а еще есть tcp. и чо? какие блядь объекты, поехавший ты?

wsdl - это удобно.

такие как ты тормозят прогресс

уже есть хттп, на чистом хттп можно писать отличные сервисы

нет, хотим объекты, хотим жрать говно

а еще есть tcp. и чо? какие блядь объекты, поехавший ты?

wsdl - это удобно.

такие как ты тормозят прогресс

такие как ты просто тормозят.

wsdl просто охуенен.

надо отдавать что-то на сторону - пишешь wsdl хоть ручками. генеришь wsldем контракты и реализуешь сервис, отдаешь на сторону wsdl - они у себя генерят контракты и реализуют клиент. profit

Через soap общаются только внутренние сервисы К тому же как ты будешь транзакционность через REST реализовывать? Это в ваших говносайтах 99,9999% операций, это тупой CRUD, в EE на пару порядков все сложнее

хехе

диман все еще считает что кроме его ынтерпрайза только говносайтики бывают

хехе

 

диман все еще считает что кроме его ынтерпрайза только говносайтики бывают

С точки зрения архитектуры -- да. 99,999% сайтов укладываются в 3-4 кубика с 5 стрелочками, может какие-то мелкие детали отличаются, типа фреймвёрк другой используется, или база не реляционная, а документоориентированная. Но суть одна

Есть знатоки алгоритмов?

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

упорядоченно хранить элементы могут все структуры на основе деревьев поиска

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

различия бывают только в сложности операций записи \ поиска \ удаления и по количеству потребляемой памяти.

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

вставлять большие числа может будет в среднем O(n), а удаление маленьких чеще всего близко к O(1), тк все будут в начале

гайс. объясните (если вдруг тут кто-то знает такие вещи). в каком виде хранится и как потом запускается программа написанная под дос (для которых нужен досбокс).

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

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

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

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

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

кросплатформенный только код программы, компиляция для каждой платформы отдельно

за исключением чего-то типа джавы где код выполняет не скомпиленая программа, а виртуальная машина джавы даёт инструкции для ОС, но для этого ВМ должна сущесововать для каждой оси отдельно

осопроблемы

гайс. объясните (если вдруг тут кто-то знает такие вещи). в каком виде хранится и как потом запускается программа написанная под дос (для которых нужен досбокс).

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

 

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

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

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

ну и банально досовские ехешники как и сказал дедскин используют функции из библиотек доса, которые уже давно канули в лету.

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

Ну и в принципе ничего не смогло бы запуститься, тк у исполняемых файлов никсов формат ELF, а не ЕХЕ.

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

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

а портабл версии вообще не имеют к этому отношения. Так называют программы, которые всё своё хранят в одном файле для удобства переноски и отсутствия необходимости в какой-либо установке.

спасибо

еще вопрос.

все че-то с кутэ работают, меня заинтересовало что это вообще и почему так популярно (кстати почему? потому что кроссплатформенно, современно и удобно? или что-то еще?).

почитал, в вики определение - "кроссплатформенный инструментарий разработки ПО на языке программирования C++".

что входит в инструментарий? компиляторы под разные оси? среда разработки своя? что-то еще?

еще слышал выражение "библиотека Qt" - это вообще что?

заранее спасибо

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

Ты только говоришь, что именно рисовать в пределах возможностей qt

ну и банально для winapi майкрософт не выпустила никакого редактора для чайников. Или хотя бы полноценную оопшную обертку

Только чистый процедурный, только хендлы, только хардкор.

Поэтому такую популярность и получил Delphi\BorlandC++, ведь борланды обернули винапи в удобные объекты, ввели полноценную событийную модель и дали ебаный редактор, где можно мышкой накидать интерфейс и не ебаться с самостоятельным рассчетом пикселей и невозможностью проверки без запуска.

а под никсами я вообще хз как пишут, кроме qt

а, gtk+ под никсами же

под никсы не мало либ для гуев, даже на питоне можно бацать, рикомендую

еще вопрос.

все че-то с кутэ работают, меня заинтересовало что это вообще и почему так популярно (кстати почему? потому что кроссплатформенно, современно и удобно? или что-то еще?).

почитал, в вики определение - "кроссплатформенный инструментарий разработки ПО на языке программирования C++".

что входит в инструментарий? компиляторы под разные оси? среда разработки своя? что-то еще?

еще слышал выражение "библиотека Qt" - это вообще что?

заранее спасибо

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

по сути

Как где что рисовать будет ебать уже их, а не тебя.

Ты только говоришь, что именно рисовать в пределах возможностей qt

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

- ты берёшь доки qt, пишешь скажем на с++ гуи который соответствует этой библиотеке

- компилишь код под винду виндовым компилятором с++ и к проге в довесок кидаешь виндовую версию библиоетки

- компилишь под никсы - так же добавляешь никсовую версию qt к своей программе

- наблюдаешь результат: под обоими платформами будет отрисован написаный тобой гуи

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

еще вопрос.

все че-то с кутэ работают, меня заинтересовало что это вообще и почему так популярно (кстати почему? потому что кроссплатформенно, современно и удобно? или что-то еще?).

почитал, в вики определение - "кроссплатформенный инструментарий разработки ПО на языке программирования C++".

что входит в инструментарий? компиляторы под разные оси? среда разработки своя? что-то еще?

еще слышал выражение "библиотека Qt" - это вообще что?

заранее спасибо

удачи тебе потом искать работу с этим популярным инструментом

еще вопрос.

все че-то с кутэ работают, меня заинтересовало что это вообще и почему так популярно (кстати почему? потому что кроссплатформенно, современно и удобно? или что-то еще?).

почитал, в вики определение - "кроссплатформенный инструментарий разработки ПО на языке программирования C++".

что входит в инструментарий? компиляторы под разные оси? среда разработки своя? что-то еще?

еще слышал выражение "библиотека Qt" - это вообще что?

заранее спасибо

удачи тебе потом искать работу с этим популярным инструментом