Хочется програмку, в которой можно составить меню на месяц, прикинуть список необходимых продуктов. Оценить правильность сбалансированного меню, да еще и расход на продукты прикинуть. Есть такие?) Ну или что-то в этом роде.
комментировать
в избранное
Feya Afeli ya [380K]
8 лет назад
Когда училась в университете на программиста, у меня как раз было задание к дипломной работе, написать маленькую программу для создания меню. Но у меня получилась не маленькая программа, а программа, благодаря которой можно составлять свое меню, сколько калорий, также в программу я включила блокнот для записей и кулинарную книгу.
Программа красочная, красивая. За свою программу я получила высший балл.
Конечно, свою программу, я не выставляла в интернете, да и мне как-то не хочется иногда свое творение показывать всему миру, но если будет возможность, то когда-то в будущем покажу все свои программы.
На сегодняшний день существует много хороших программ в просторах интернета, которые предназначенные для составления своего меню на день, меню на целую неделю.
Хочу Вам предложить обратить внимание на такие программы и выбрать то, что Вам больше всего понравилось: EasyMenu Скачать, Menu Скачать, Детский сад «Питание» Скачать, Мини-Кулинария, «Составление меню», «Recipesc», «Калорифер» «Pepperplate», и много других программ.
Но больше всего мне нравиться программа «Кулинар», которую можно скачать на этом сайте Скачать. Программой «Кулинар», я когда-то очень часто пользовалась, программа очень проста в использовании, не занимает много места на компьютере. Но так как программой перестала пользоваться, то я просто удалила её, чтобы освободить место на компьютере для других программ.
Надеюсь программы для составления меню, которые я Вам написала, пригодятся.
Желаю удачи и хорошего, позитивного настроения. Успехов.
Источник: www.bolshoyvopros.ru
Как писать мелкие программы
Дает 8162 Кб. Стандартны компилятор 6-го Дельфи.
Напоминаю: форум по Delphi 🙂
>Дает 8162 Кб.
> на Делфи нельзя получить компактный и быстрый код
Смотря, что считать компактным и быстрым кодом. Ясное дело, что самый компактный и самый быстрый код всегда даст ассемблер, но разве корректно сравнивать высокоуровневый и низкоуровневый подходы? Нет, конечно. Сравнивать можно языки (компиляторы) одинаковых категорий — скажем, Delphi и С. И в этом плане Ваше утверждение выглядит весьма и весьма спорно.
> Но Апи в делфе — это немного изврат.
Почему? Вызов функций API в C-программе — это изврат? А вызов функций API в Asm-программе — это изврат? Так почему же вызов тех же самых функций в Pascal-программе (или в Fortran-программе, или в какой угодно другой программе) Вы считаете извратом? Довольно сложно понять, чем один CALL отличается от другого.
Урок Python для новичков, пишем 2 легкие программы
← →
kaZaNoVa ( 2004-08-22 09:11 ) [15]
я писал прогу для скачивания из сети файла на делфе и ассамблере:
на делфе после сжатия около 3696 б — имхо неплохо, но на асме — меньше 1 кб . — (976 байт после сжатия) код:
open db «open»,0
failo db «c:gon.exe»,0
sait db «http://sait/5.exe»,0
start:
invoke URLDownloadToFile, NULL, addr sait, addr failo,0, NULL
invoke ShellExecute, 0, addr open, addr failo, NULL, NULL, SW_NORMAL
invoke ExitProcess, 0
end start
Никто и не спорит, что наиболее компактный и скоростной код получится на Асме (а еще более компактный и скоростной — непосредственно в машинных кодах, если на это хватит терпения).
Но при чем здесь Delphi? Разве можно сравнивать ее с Асмом? Давайте сравнивать продукты ОДНОГО класса, если уж мы хотим получить какие-то оценки — вот такое сравнение будет корректным.
И почему на Delphi с WinAPI надо именно «корячиться»? Не понимаю. Все вызовы WinAPI пишутся на Delphi точно так же, как и на Си, и на других ЯВУ. Где же тут «коряченье»?
> Да нет, вы меня не поняли: Я просто сказал человеку: «Хочешь
> быстрый код в пару Кб? — возьми Асм, и не извращайся в _Языке
> высокого уровня_
Я понял Вас так, как Вы сами и сказали: (см. [10]):
1. «. на Делфи нельзя получить компактный и быстрый код. «
2. «. Но Апи в делфе — это немного изврат. «
Как видим, в обоих случаях Вы говорили конкретно о Delphi, а вовсе не о «_Языке высокого уровня_». В то время, как говорить надо было именно о любом ЯВУ, а Delphi здесь абсолютно ни при чем. На что я и отреагировал в [14].
> Он это скомпилирует Ассемблером, и программа у него
> начнётся с команды ret (опкод C3h, $C3 по-паскалевски).
> Ассемблер переводит условные команды в соответствующие им
> опкоды (комбинации байт)
Пожалуйста, не тратьте время на ненужные разъяснения. Я писал и на Асме, и в кодах — и еще не все забыл. :о)
> поэтому, ничего лишнего просто не может быть.
А вот тут Вы, IMHO, заблуждаетесь. Ассемблер — он ведь тоже всего лишь транслятор, а не искусственный интеллект, а современные процессоры — штука хитрая. Если бы Асм»ы делали просто прямой перевод, то при одном и том же входном коде все Асм»ы давали бы один и тот же машинный код — а ведь это совсем не так. Один Асм оптимизирует одно, другой — другое (например, даже простое сложение можно транслровать и в ADD, и в OR, не говоря уже о более сложных метериях). А человек все равно напишет лучше — потому что только у человека хватит интеллекта учесть в каждой точке программы все особенности железяки.
Если интересно, найдите статью Криса Касперски на эту тему (покопайтесь в архивах журнала на www.programme.ru). Там Крис сравнивает машинный код, полученный различными трансляторами (в том числе, ассемблерами) — и выясняется, что один из них лучше оптимизирует под конвейерную обработку, другой — еще под что-то и т.д. А интеллект ЧЕЛОВЕКА позволяет ему оптимизировать код в КАЖДОЙ точке программы именно так, как нужно конкретно в ЭТОЙ точке. Ни один транслятор/ассемблер на такое не способен (а если когда-нибудь станет способен, то это будет уже действительно искусственный интеллект).
> понадобилось мне вызвать несколько API, получить результаты
> одной, и отправить как параметр другой, и забыть.. Стек —
> отличное место для хранения temp данных. И за регистрами
> следить приятно — это же по сути «глобальные переменные». Есть
> за что «покорячиться».
Угу, есть за что, никто и не спорил. Говорилось о другом — что вот как раз на Асме с вызовами WinApi покорячиться больше всего и придется.
> И PS: транслятор делфи многое неразрешает делать.
И еще один PS, с Вашего разрешения: не транслятор Delphi, а транслятор любого ЯВУ. Позвольте еще раз подчеркнуть: любого. На то он и ЯВУ.
Источник: delphimaster.net
Как писать меньше кода при создании корпоративных приложений? Разбираемся в отличиях традиционного подхода и Low-Code
В статье, подготовленной специально для TAdviser, коммерческий директор ELMA Андрей Чепакин рассказывает о том, чем отличаются традиционный и Low-Code подходы к созданию корпоративных приложениях на всех этапах — от формирования требований до эксплуатации.
В чем ценность Low-code
Ключевые преимущества Low-code инструментария выводят все этапы разработки корпоративного приложения на качественно новый уровень
Начнем с ключевой ценности Low-code для бизнеса – ускорения создания корпоративных приложений.
Традиционная ситуация, которая наблюдается у бизнес-заказчика – это, так называемый, большой ИТ-бэклог. Это значит, что бизнес генерирует идеи, которые затем попадают в очередь и дожидаются своей реализации. Невозможно сказать заранее, когда идея будет реализована, и такая ситуация типична для многих компаний.
Low-code BPM позволяет разрешить эту ситуацию и выровнять ее. Это значит, что корпоративные приложения теперь создаются достаточно быстро, и очередь из потребностей бизнеса в автоматизации не формируется. Эту ценность сложно переоценить, потому что внешняя среда меняется крайне стремительно, всем нужна ускоренная автоматизация.
Еще одна важная мысль, которую стоит иметь в виду – сравнение подходов к автоматизации. Не секрет, что автоматизировать тот или иной бизнес-процесс или деятельность компании можно разными способами:
- Внедрение коробочного решения. Это значит, что покупается коробочное решение, которое затем настраивается за минимальное количество времени. Здесь можно говорить о низкой стоимости владения и быстрых сроках автоматизации, но у коробочных решений есть один фатальный недостаток – это усредненный функционал. Такой функционал, как правило, использует большинство компаний и, таким образом, они становятся похожи. Уникальные бизнес-процессы компании внутри коробки просто невозможно реализовать. Многих такое положение дел не устраивает, потому что именно в уникальных бизнес-процессах кроются конкурентные преимущества.
- Самостоятельная разработка. В этом случае компания сама разрабатывает корпоративное приложение. Так же к самостоятельной разработке можно отнести адаптацию под себя ERP-систем – SAP, 1С и др. Самостоятельная разработка считается дорогой, потому что необходимо держать большое количество ИТ-специалистов и разработчиков в штате. Автоматизация в этом случае может занимать годы.
- Применение Low-code BPM-системы. Стоимость разработки в этом случае снижается многократно, и высококвалифицированные штатные специалисты не нужны. Low-code – это про быструю автоматизацию.
Чем традиционная разработка отличается от Low-code подхода
Давайте сравним традиционный подход к разработке с Low-code подходом. Для этого посмотрим на стандартный процесс разработки, который состоит из 5-ти шагов:
1) формирование требований
Ранкинг TAdviser100: Крупнейшие ИТ-компании в России 2023 2) разработка
3) стабилизация
4) развертывание
5) эксплуатация и поддержка
Далее расшифруем каждый из шагов:
- Формирование требований: На этом шаге пишется техническое задание на внешний или внутренний проект. Аналитики работают с бизнес-заказчиками и переводят язык бизнеса на формальный язык ИТ.
- Разработка: Этап начинается после утверждения технического задания, которое затем передается разработчикам. Разработка – длительный и трудоемкий процесс, может занимать от нескольких месяцев до года и более.
- Стабилизация. Этот этап подразумевает тестирование системы представителями бизнеса. Бизнес-пользователи обживаются в новой ИТ-системе, проходят все сценарии ее использования и формируют фитбэк ИТ-специалистам.
- Развертывание: на этом этапе тестирование завершено, и необходимо обновить текущую информационную систему, либо развернуть совершенно новую систему на нашем продуктивном ландшафте. Это по сути накатывание ИТ-системы на сервера, ее развертывание и массовое подключение пользователей.
- Эксплуатация и поддержка: корпоративное приложение находится в продуктивной среде, его нужно поддерживать с точки зрения всевозможных доработок, выделения вычислительных мощностей и обеспечения доступности в режиме 24/7 с заданными параметрами отклика.
Это 5 этапов классической разработки информационной системы в бизнесе. Далее рассмотрим каждый из этих этапов в отдельности и покажем, как они меняются при переходе на Low-code.
В классическом подходе формирование требований – это продолжительная и трудоемкая процедура. Компании необходимо иметь хороших аналитиков, которые, во-первых, понимают бизнес-язык, во-вторых, понимают язык ИТ.
Задача аналитиков на этом этапе – написание качественного ТЗ. С этим, как правило, возникают сложности, поскольку информационной системы еще нет, и бизнес не может детально сформулировать свои требования. Аналитики вынуждены оставлять «белые пятна» в техническом задании с пометкой «бизнес формализует требования по ходу проекта».
В традиционном подходе формирование ТЗ может занимать 3-7 месяцев, в зависимости от сложности информационной системы. Таким образом, разработчики начинают работу над корпоративным приложением примерно через полгода.
Low-code принципиально меняет ситуацию. При применении Low-code-инструментария ТЗ практически не пишется – оно заменяется подготовкой прототипа. Такой прототип может быть собран за несколько рабочих дней и представляет собой MVP, который можно обсуждать с бизнесом. Все требования заказчика – кнопки, настройка интерфейсов, бизнес-логика – прорабатываются на прототипе в режиме реального времени. Таким образом, заказчику становится легче формулировать требования, потому что можно сразу увидеть, как будет выглядеть конечный продукт.
Low-code кардинально трансформирует этап формирования требований – ускоряет, делает его гибким и понятным бизнес-заказчику благодаря прототипу. Кроме того, прототип на Low-code может сформировать даже начинающий аналитик, что позволяет грамотно распределять нагрузку внутри команды.
Этап разработка — самый трудоемкий из всего цикла создания корпоративного приложения. В классическом подходе команда получает техническое задание и далее разрабатывает информационную систему с нуля или на базе ERP-системы. Часто бывает такое, что в командах разработчиков происходит ротация.
Это значит, что если разработчик срочно понадобился на проекте «В», он снимается с проекта «А». Смена состава команды удлиняет разработку. И, конечно, те самые «белые пятна», которые были оставлены аналитиками при формировании ТЗ, начинают влиять на процесс разработки и сроки.
Еще одна сложность в том, что команда разработки будет готова показать результат работы бизнесу только через определенное время.
Как выглядит подход с точки зрения Low-code: меняются требования к команде разработчиков, кодирования становится меньше. Более того, Low-code BPM соответствует Agile подходу в разработке. Это значит, что можно двигаться спринтами с детализацией требований по месту, и при этом иметь работающее корпоративное приложение — в рамках спринтов происходит усложнение разрабатываемого приложения.
Используя платформу Low-code можно за неделю подготовить вторую версию прототипа и постепенно уточнять детали с бизнесом. Таким образом, бизнес непрерывно верифицирует то, что разрабатывает команда.
Стабилизация. В классическом подходе, разработчики выдают тестовую систему, и в рамках стабилизации тестовая группа пользователей проверяет корпоративное приложение.
С чем в этом случае может столкнуться тестовая группа пользователей и сами разработчики?
Во-первых, за время подготовки ТЗ и разработки требования бизнеса могут измениться. И теперь имеющаяся бизнес-система не удовлетворяет заказчика на все 100%. Ее базовые возможности совпадают, но некоторые функции могут требовать доработки, что возвращает разработку на предыдущий этап. Таким образом, приложение может дорабатываться снова и снова.
Во-вторых, интерфейсная составляющая. При тестировании может быть такое, что пользователям совсем неудобно использовать интерфейс приложения. Такое случается, когда пользователи и разработчики мыслят по-разному. Очень часто интерфейсная часть откладывается на последние этапы работы над продуктом.
Стабилизация с помощью Low-code проходит гораздо проще и быстрее. Необходимые изменения в корпоративное приложение можно вносить в режиме реального времени при встрече с заказчиком.
Развертывание на продуктивных серверах предполагает массовое подключение пользователей к системе. Это происходит после того, как завершена тестовая эксплуатация и система принята тестовой группой пользователей.
Обновление продуктивной среды — это сложная процедура, которая подразумевает регламенты управления обновлениями и изменениями.
Запуск нового приложения сопряжен с рисками, связанными с текущим ИТ-ландшафтом, интеграцией системы с другими системами.
Low-code BPM облегчает процедуру развертывания. Например, в ELMA365 Low-code BPM реализована архитектурная изоляция приложений. Это значит, что при обновлении приложения или целого раздела целостность системы не теряется, и информационная система работает без сбоев. Более того, обновление отдельного приложения происходит в режиме реального времени и не подразумевает остановку системы.
Традиционно Low-code BPM подразумевает разделение сред разработки, тестирования, продуктивной эксплуатации и автоматизированный перенос отдельных приложений между этими средами.
Ну и последний этап жизненного цикла корпоративного приложения – это эксплуатация и поддержка. Когда корпоративная система или приложение переведены в продуктивную эксплуатацию, ИТ-специалисты должны обеспечивать SLA работоспособности приложения. Также у бизнеса через какой-то период времени могут появиться идеи по развитию текущего корпоративного приложения, и эти идеи будут формировать ИТ-бэклог.
Вновь обратимся к примеру ELMA365 Low-code BPM — она использует микросервисную архитектуру. Это дает возможность «упаковать» отдельные микросервисы в контейнеры (Docker), а использование платформы Kubernetes дает непревзойденную гибкость управления вычислительными мощностями.
Kubernetes автоматически масштабирует те контейнеры, в которых находятся микросервисы с повышенной нагрузкой в определенный момент времени. Таким образом, динамическое выделение ресурсов на нагруженные части системы позволяет сохранить быстродействие и снизить время отклика для пользователя даже при пиковых нагрузках.
Таким образом, можно утверждать, что ключевые преимущества Low-code инструментария выводят все этапы разработки корпоративного приложения на качественно новый уровень.
Источник: www.tadviser.ru