Приветствую тебя, дорогой читатель! Очень надеюсь, что данный пост все таки сможет достичь тех людей, которые так или иначе разрабатывают программное обеспечение не только для себя и своих пользователей, но и для широкой аудитории.
В первую очередь речь пойдет о “корпоративном сегменте”: различные программы электронного заказа и прочее подобное ПО, которое приходится внедрять в свои системы системным администраторам и часто плакать кровавыми слезами от наблюдения за одними и теми же ошибками разработчиков.
Я понимаю. что большинство подобных программ пишутся не высокими специалистами, а чаще даже системными администраторами у которых и без того времени ни на что не хватает, но как только программа выходит на более широкую аудиторию, пожалуйста, соизвольте соблюсти несколько ВАЖНЫХ правил хорошего тона и безопасности.
1. Установка приложения
1.1. Папка установки по-умолчанию
По какой-то непонятной мне причине, большинство программистов в своих исталляторах зашивают путь установки что-то вроде:
Как изменить программу открытия файла по умолчанию
C:ProgramName
Нам еще повезет, если инсталятор предложит его изменить, но поверьте, немногие позволяют это сделать.
Уважаемые программисты, пожалуйста, всегда (. ) просите пользователя указать папку, куда он желал бы установить ваше рукоделие. Никогда (. ) не используйте преднастроеные пути вроде вышеуказанного. В крайнем случае укажите в инсталяторе один из следующих путей:
%ProgramFiles%ProgramName %ProgramFiles(x86)%ProgramName
Объясню почему это так важно: У многих администраторов настроены политики безопасности таким образом, что приложения могут запускаться ТОЛЬКО из %ProgramFiles% директории. В случае с установкой в корень диска C:, мы чаще всего получим неработающий кирпич, который, даже не всегда, можно копированием перенести в %ProgramFiles% после установки- посыпаются ошибки.
Ну и конечно же, представьте сколько вас таких, желающих запускаться из C:ProgramName. Представляете, какой это вносит хаос в файловую систему ПК пользователя, а так же в политики безопасности компании?
1.2. Название приложения и директории установки
Все по той же непонятной мне причине, многие программисты называют свои программы только им понятными символами, вроде: ELRG. Только подготовленный пользователь сможет угадать, что за этой аббревиатурой скрывается, ни что иное, как “Elektronniy Zakaz Roga Kopita”. Да, на русском, в транскрипции. Я не против транскрипций, но сделайте понятные названия.
Если вы создали приложение и даже обозвали его как-то, то пожалуйста, используйте корректные наименования ваших продуктов. Очень часто встречаю дефолтные значения различных инсталяторов вроде “ProgramName v.0.0” (именно так, без прикола).
Не забудьте так же, и про директорию установки (её название должно соответствовать названию программы), а так же про наименование приложения в оснастке “Установка и удаление программ” (да, сюда тоже ваше приложение необходимо вносить, но об этом позже).
Операция не может быть завершена, так как файл или папка открыта в другой программе
Для чего это все? Чтобы системный администратор просто взглянув на директорию/название ярлыка/название ПО в Установке и удалении мог сразу понять что это, зачем это, где это.
1.3. Дополнительное программное обеспечение
Если для работы вашего ПО, необходимо какое-либо еще программное обеспечение (читай библиотеки/либы/флеймворки), не забудьте указать это в инструкции к программе (она же у вас есть, правда?), а так же позвольте пользователю установить его сразу, вместе с вашей программой.
Как можно установить дополнительное ПО?
- Жестко зашить его в инсталлятор и проверять его наличие перед установкой и устанавливать, если отсутствует. Не забудьте его удалить за собой после удаления программы или после обновления, если дополнительное ПО уже не требуется в новой версии.
- Положить инсталятор “рядом” с основным инсталлятором вашего ПО, чтобы администратору не искать в интернете “нужную” версию вашего любимого флеймворка, чтобы ваша программа заработала.
В случае отсутствия какого-либо компонента, при запуске ПО, не забудьте четко вывести ошибку с описанием проблемы, например так:
Урок 24 Правильные имена файлов
Здравствуйте, читатели сайта IT-уроки! Сегодня вас ждёт урок с маленьким, но важным секретом. А относится этот секрет к правильным именам файлов.
Почему-то начинающим пользователям никто не говорит, как лучше называть файлы. Но незнание простого правила может стоить немало нервов и времени.
Этот урок будет очередным шагом в повышении безопасности и надежности хранения данных.
Как правильно называть файлы?
В прошлом уроке мы разобрались с именами папок, сегодня движемся дальше и узнаем, как правильно называть файлы.
Для простоты понимания, начну с примеров НЕправильных имён файлов.
Пример первый (плохо)
Вам нужно написать отчет/доклад/диплом/резюме (нужное подчеркнуть). Вы открываете Word, набираете текст, сохраняете под именем «Отчет». Вроде бы всё нормально, не так ли? На следующий день вы решили доработать своё творение, открываете, изменяете, жмете кнопку сохранить, и… получаете тот же файл «Отчет», но с другим содержимым. Здесь уже стоило бы задуматься.
В какой-то момент вы вдруг поняли, что старый вариант был лучше. Но вы уже удалили часть своего отчета, заменив новым текстом.
Придется эту часть текста придумать заново? К сожалению, да. Но второй раз так красиво не получится? Вполне возможно.
Пример второй (еще хуже)
На третий день, продолжая работать над своим отчетом, вы отходите на кухню за чашкой чая, оставив окно программы открытым (никогда так не делайте). Конечно же, это самый подходящий момент добраться до клавиатуры ребенку/коту/тряпке_для_пыли (нужное подчеркнуть).
Вернувшись с чаем вы обнаруживаете что-то похожее на шифр от инопланетян «ывадж юбрн7 ыфва шруцз89 фыва0=== 232 вцуацуфаца» вместо отточенного за долгие дни текста…
И это чудесное послание сохранено.
Придется набирать ВЕСЬ ТЕКСТ заново? Очень жаль, но это так.
Как же быть?
Чтобы не попасть в такие неприятные ситуации, нужно научиться правильно называть файлы. Для этого следуйте рекомендации от сайта IT-уроки:
Всегда сохраняйте новую версию файла с новым именем.
Но чтобы не наводить беспорядок, новое имя должно быть похоже на старое (на основе старого). Отсюда дополнение к рекомендации:
К имени новой версии файла добавляйте номер.
Иногда важна не только версия, но и нужно знать дату, когда вы внесли изменения. В этом случае:
К имени файла можно добавить дату в формате ГОД-МЕСЯЦ-ДЕНЬ.
Почему именно в таком виде? Всё просто, в проводнике файлы будут сортироваться в правильном порядке (по дате и версии).
На рисунке ниже названия файлов одного из IT-уроков:
Пример правильных имён файлов
Да, у вас будет целый набор файлов с похожими именами, и это именно то, что нам нужно. Сейчас объясню на примере:
Пример третий (хорошо)
Вы набираете текст в документе (отчет/доклад/диплом/резюме) и периодически сохраняете его под новым именем: «Отчет 01», через полчаса «Отчет 02», на следующий день «Отчет 03» и так далее.
Что делать, если на следующий день вы изменили часть текста и сохранили документ как «Отчет 04», а потом решили восстановить старый вариант (как в первом примере с Пушкиным)? Просто откройте «Отчет 03» и скопируйте нужный текст в новую версию.
Под каким именем сохранить исправленный документ?
Правильно, «Отчет 05»! Быстро учитесь
Пример четвертый (отлично)
Есть документы, для которых немалую роль играет дата их создания, например, резюме. В этом случае вы можете создать файл «Моё резюме 20140108». После следующего изменения вы сохраните его как «Моё резюме 20140201».
Возможно, вам понадобится создать несколько версий документа в один день, поэтому лучше добавлять и дату, и номер версии: «Моё резюме 20140201-02».
Кажется, хватит примеров.
Заключение
Сегодня мы с вами разобрались, как лучше называть файлы. Было много примеров и описаний, поэтому подведу итог в виде вот такой формулы с правильными именами:
Формула правильных имен файлов
На сегодня всё, а вы в комментариях можете поделиться своей формулой правильных имён файлов и папок.
P.S. Следующий урок будет самым важным в этой серии, не пропустите! Подписаться на новости сайта можно по этой ссылке или с помощью специальной формы ниже.
Копирование запрещено, но можно делиться ссылками:
Источник: it-uroki.ru
Make files not war: что такое утилита GNU make, зачем ее использовать и как это делать правильно
В этой статье мы поговорим о некоторых тонкостях работы с утилитой GNU make , а также научимся писать простые и аккуратные make-файлы. Последнее особенно важно — make-файлы выглядят сложно и нечитабельно, если им не уделить должного внимания. Это обеспечивает make плохую репутацию, хотя на самом деле инструмент крайне удобный, особенно для автоматизации сборки.
В большинстве проектов, будь то разработка ПО, написание книги или публикация записи в блоге, в какой-то момент приходится генерировать «конечные продукты» из вручную написанных исходных файлов, то есть осуществлять сборку.
Суть автоматической сборки состоит в том, чтобы взять за основу генерацию какого-то одного элемента, вычленить правила, по которым она происходит, и применить их к большему количеству элементов такого же типа, обновляя только изменяемые параметры.
Это может быть сделано (и часто делается) под определенную задачу с помощью кастомных скриптов, но мы в данной статье рассмотрим, как можно удобно автоматизировать сборку, используя утилиту make и её встроенные правила.
Почему стоит использовать утилиту make
- она работает;
- легко настраивается как для новых, так и для существующих проектов;
- в большинстве ОС она предустановлена, если нет — её легко скачать;
- она крошечная и содержит мало зависимостей;
- make-файлы всё-таки могут быть короткими, ёмкими и красивыми;
- она не использует загадочные папки типа working или resource ;
- да и вообще темной магией не занимается — всё на виду.
Пишем make-файлы
Создадим файл и назовем его makefile или Makefile . Содержание стандартного make-файла можно описать так: «если любой из файлов-пререквизитов был изменен, то целевой файл должен быть обновлен». Суть make в том, что нам нужно по определенным правилам произвести какие-то действия с пререквизитами, чтобы получить некую цель.
Инженер миграции Astra Linux АО «Гринатом» , Москва , От 50 000 до 100 000 ₽
Правила, которые и составляют основу make-файла, по сути являются командами и могут быть сколь угодно сложными, а также могут содержать в себе вызов других инструментов, таких как компиляторы и парсеры.
Базовый синтаксис для определения цели (в файле makefile ):
цель: реквизит1 реквизит2 . команда1 команда2 .
Важно Индентация производится с помощью табуляции, а не пробелов.
В командах описывается, что make должна сделать, чтобы создать целевой файл. Они исполняются, когда мы делаем запрос на создание или обновление целевого файла и make заключает, что пререквизиты изменились или целевой файл еще не существует.
Часто нам нужно обрабатывать несколько файлов одного вида по одним и тем же правилам. Например, при создании страниц HTML на основе размеченного текста. Это делается с помощью шаблонных правил, наличие которых является отличительной чертой make в сравнении с обычной сборкой через командную строку.
Шаблонные правила работают на основе сопоставления расширений файлов. Например, make знает, как создавать объектные файлы *.o из исходных C-файлов *.c , компилируя их и передавая компилятору флаг -c . В make есть несколько встроенных шаблонных правил, самые известные из которых используются для компиляции кода на C и C++.
Теперь мы можем упростить make-файл, избегая написания команд в случаях, когда make сама знает, что делать. Главное, не забывать ставить пустую строку после цели — make это нужно, чтобы определять, где кончается одна цель и начинается другая.
В большинстве случаев мы можем даже опустить пререквизиты: внутренние правила make подразумевают, что для того, чтобы, например, собрать somefile.o по принципу Исходник на C → Объектный файл, нам нужен somefile.c .
Будьте аккуратны: когда вы предлагаете make свой список команд, она будет ориентироваться только на ваш код и в данном случае не будет искать шаблонные правила для сборки цели.
Вызываем make
Запустим make в текущей директории:
make
Если make-файл в ней уже есть, будет создана (собрана) первая цель, которую make сможет найти. Если make-файла нет (или он есть, но в нем нет целей), make об этом сообщит.
Чтобы обратиться к конкретной цели, запустите:
make [цель]
Здесь цель — это название цели (без квадратных скобок).
make может догадаться, что делать, используя встроенные правила, без дополнительной информации от пользователя. Попробуйте создать файл test.c в пустой папке и запустить make . test.make скомпилирует test.c , используя встроенное шаблонное правило, и соберет цель с названием test . Это сработает даже через несколько шагов генерации промежуточных файлов.
Специальные цели
В большинстве make-файлов можно найти цели, называемые специальными. Вот самые распространенные:
- all — собрать весь проект целиком;
- clean — удалить все сгенерированные артефакты;
- install — установить сгенерированные файлы в систему;
- release или dist — для подготовки дистрибутивов (модули и тарболы).
Они не обязательно должны присутствовать в make-файле, но большинство сборочных процессов странно представить без хотя бы первых трех.
При сборке этих целей не будут созданы файлы с именами, например, all или clean . make обычно решает, запускать ли какие-либо процессы, основываясь на данных о том, нужно ли изменять целевой файл. Создание файлов с подобными именами не даст make произвести никаких изменений с целями.
Для предотвращения этого GNU make позволяет помечать такие цели как «фиктивные» (phony), чтобы запускать их в любом случае. Сделать это можно, добавив необходимые цели в качестве пререквизитов во внутреннюю цель .PHONY следующим образом:
.PHONY: all clean run
Цель all обычно просто содержит главный исполняемый файл в пререквизите — иногда с дополнительными командами для пост-обработки генерируемых файлов. Так как мы в большинстве случаев хотим, чтобы цель all исполнялась по умолчанию, она должна стоять первой в файле.
Для цели clean стоит добавить список команд, удаляющих все генерируемые файлы. Это может быть легко сделано с использованием переменных, о которых мы поговорим в следующем разделе.
Переменные и функции
Как и в большинстве языков программирования, make-файлы можно сделать более читабельными, используя переменные. make импортирует свою среду, позволяя нам определять переменные внутри файла через внешние источники.
Основные операции
Определять переменные и ссылаться на них можно следующим образом:
NAME = value FOO = baz bar = $(FOO) frob
Ссылаться на переменные можно через $(NAME) или $ . Если опустить скобки, make сочтет за имя переменной только первый символ. Присоединение осуществляется при помощи оператора += . Можно также задать условные переменные с помощью ?= (если им еще не присвоены значения).
Наконец, большинство реализаций make позволяют нам задать выходную переменную с помощью оператора != при порождении одного подпроцесса за операцию.
Передача аргументов встроенным шаблонным правилам
Ранее мы видели некоторые шаблонные правила в действии, правда, во всех случаях они запускали одни и те же базовые команды. Конечно, требования к сборке не всегда одинаковы, и инструменты могут запрашивать разные флаги для разных задач.
Например, какому-то ПО нужно обеспечить соединение с разными библиотеками, или заданные оптимизации различаются для сборки отладки и итоговой сборки.
Поэтому встроенные правила в make включают в себя несколько распространённых переменных в важных местах команд. Мы можем установить их по желанию из make-файла или внешней среды.
Это позволяет, например, запускать один и тот же make-файл с разными компиляторами, снабдив make необходимым именем бинарного файла для выполнения. Так задаётся переменная среды компилятора C:
CC=clang make
Вот некоторые из самых известных переменных, которые вы могли видеть, если когда-нибудь заглядывали в make-файл:
- $(CC) / $(CXX) — бинарные файлы для компиляторов C и C++, которые make использует для сборки;
- $(CFLAGS) / $(CXXFLAGS) — флаги, передаваемые компиляторам;
- $(LDLIBS) — присоединяемые библиотеки.
Программные переменные
make хранит некоторые распространённые программы в переменных. В основном это делается для того, чтобы при необходимости их можно было перезаписать.
Самая важная из них — $(MAKE) , которая должна использоваться при рекурсивном вызове make из make-файла. Она принимает во внимание аргументы командной строки из исходного вызова.
В цели clean , главная задача которой — удаление файлов, безопаснее использовать переменную $(RM) вместо прямого вызова rm .
Функции нескольких переменных
GNU make определяет некоторые очень полезные методы, большинство которых работает со словами, то есть с разделенными пробелами строками символов. Это облегчает работу с переменными, содержащими в себе списки файлов.
Функции вызываются таким же образом, как вызывалась бы переменная с таким же именем, но с добавлением аргументов перед закрывающей скобкой.
Вот некоторые наиболее интересные методы:
- $(wildcard шаблон) возвращает список с названиями файлов, соответствующих шаблону, которые в том числе могут представлять собой относительный путь. Список внутри разделен с помощью пробелов, что проблематично для работы с файлами, содержащими пробелы в названии. Лучше всего избегать таких файлов при работе с make . Шаблон может содержать универсальный символ * ;
- $(patsubst шаблон поиска, шаблон замены, список слов) заменяет все слова в списке, которые соответствуют шаблону поиска в соответствии с шаблоном замены. Оба шаблона используют % в качестве символа;
- $(filter-out шаблон поиска, список слов) возвращает список всех слов, отфильтрованных по шаблону поиска;
- $(notdir список слов) возвращает список слов, где имя каждой записи сокращается до основного (то есть если имя содержит название директории, то оно отфильтровывается);
- $(shell команда) запускает команду в подпроцессоре и перехватывает стандартный вывод подобно оператору != . Оболочка для выполнения команды определяется переменной $(SHELL) .
Подробное описание функций можно найти в официальной документации.
Продвинутое использование переменных
Отсылки к переменным можно делать в любом контексте внутри make-файла. Можно даже соорудить имя исполняемого файла внутри списка команд с помощью соединения нескольких переменных. Это позволяет использовать переменные в качестве целей или пререквизитов и создавать простые конструкции типа:
OBJECTS = $(patsubst %.c,%.o,$(wildcard *.c)) all: $(OBJECTS)