RSS

Комментарии

Для начала определимся, что понимается под «высоким уровнем»? Традиционно языки программирования разделяются на поколения. Сам термин поколения языка достаточно редко используется в русской технической литературе, да и сам язык не всегда можно четко и категорично отнести к тому или иному поколению. Поэтому давайте разберемся, сначала с ним, а потом перейдем собственно к PHP.

Поколение языка к его возрасту имеет косвенное отношение. Словом «поколение» выражается лишь общие тендении и абстрактность языковых терминов. Даже в наши дни до сих пор создаются языки «младших» поколений, для решения каких либо конкретных задач, если для этого есть предпосылки.

Языком первого поколения является машинный код. Он и сейчас используется, в него в конечном итоге транслируют все другие языки программировния. Молодежь может быть не в курсе, но еще лет 30-40 тому назад на нем писали живые люди. Кроме шуток. Не хакеры, а прикладные программисты. Прямо так байтик по байтику составляли прикладные программы, например расчет зарплаты сотрудникам завода.

Наиболее известный представитель второго поколения — Ассемблер (ASM). С помощью него повысилась скорость написания программ и совместимость при переносе на родственное оборудование. Ассемблер не просто привел в соответствие машинным кодам какие-то мнемонические команды, а позволил абстрагироваться от многих технических деталей, позволив больше сосредоточится на решении прикладной задачи. Собственно этот последний тезис является главным признаком индукции при переходе от одного поколения языка к другому.

Третье поколение языков позволило практически полностю абстрагироваться от «железа». Их уже столько много, что перечислить затруднительно. Одни из пионеров — Фортран, Паскаль, Бейсик. Языки третьего поколения до сих пор самые используемые и кажется, что покрывают все необходимые потребности современного программирования. Однако прогресс не стоит на месте. Теория программирования сделала следующий шаг и породила четвертое поколение языков (4GL).

Не каждый язык имеет ярлык конкретного поколения и свое четкое место на шкале. Примером такого является Си. Хотя Си появился, когда эра третьего поколения была уже в разгаре, но родился он с явними признаками языка второго поколения. Это нисколько не аттавизм и не деградация. Он именно таким и задумывался – язык для написания операционных систем. Взяв все необходимые новшества и синтаксические удобства языков третьего поколения, он позволяет писать программы, практически оптимизировануми также, как на Ассемблере. Можно сказать, что он находится на отметке 2 ½ поколения.

Не меннее интересна картина с С++. Синтаксически это тот же Си с дополнительными прибамбасами. Но из-за них С++ перестал быть языком. Сам по себе он не представляет бОлшей ценности, чем Си. Интересным он становится тогда, в нем создана та или иная объектная иерархия, переопределены операторы и т.п. Когда мы получаем новую концепцию работы с данными. Практически это новый язык с Си синтаксисом, который может соответствовать любому поколению. То есть по сути С++ не язык, а инструмент для создания языков. К сожалению большинство програмистов звезд с неба не хватают. Какая бы не была навороченная иерархия объектов, созданная в С++, она будет соответствовать банальному третьему поколению языков. ООП находится в полном перпендикуляре к линии повышения абстракций.

Мы сейчас живем на стыке эпох третьего и четвертого поколения. Многие просто недопонимают самого смысла появления нового поколения, при том, что старые языки так прекрасно решают все вопросы. Суть индукции следующего шага все та же — абстракция от технических деталей с целью более быстрого решения прикладной задачи.

Здесь следовало бы привести примеры языков четвертого поколения. Перед этим необходимо сделать оговорку, что упомянутые далее языки могут обладать в той или иной мере свойствами четвертого поколения. Синтаксически это может быть не выражено явно. 4GL — это новая концепция, а не новый синтаксис. Синтаксически язык может быть похож на язык третьего поколения, но подход при работе с ним будет другим.

Формально к языкам четвертого поколения можно отнести SQL. Это наиболее известный представитель, но посколько он используется в очень узкой специфической задаче, то наглядно не демонстрирует все аспекты 4GL. Одну из ранних попыток предпринял Informix. Вместе со своей базой данных и набором стандартных библиотек для других популярных языков третьего поколения, они предлагают свой собственный язык Informix-4GL. В качестве синтаксической модели они взяли SQL и дополнив другими языковыми конструкциями сделали из него полноценную среду разработки, в котором SQL команды явлются не чем-то инородным, заключенным в кавычки, а нативной частью языка. В этом смысле к языкам четвертого поколения можно отнести семейство dBase, FoxBase, Clipper и им подобные.

Внимательный читатель может заметить из нескольких перечисленных примеров, что здесь говорится даже больше не о языке, а о среде разработки. Это будет правильное замечание, поскольку современые прикладные задачи требуют баз данных, не просто как нечто, где можно сохранить кое-какие конфигурационные данные. База данных (в широком смысле этого слова) становится ядром, вокруг которого строится приложение. Поэтому не удивительно, что она уже не хочет довольствоваться правами сторонней библиотеки (бедного родственника). Из-за естественных ограничений мы получаем ситуацию, когда не к языку привязывается база данных, а вокруг какой-то конкретной реализации базы возводится язык. Универсальные решения мне пока не известны.
Для начала определимся, что понимается под «высоким уровнем»? Традиционно языки программирования разделяются на поколения. Сам термин поколения языка достаточно редко используется в русской технической литературе, да и сам язык не всегда можно четко и категорично отнести к тому или иному поколению. Поэтому давайте разберемся, сначала с ним, а потом перейдем собственно к PHP.

Поколение языка к его возрасту имеет косвенное отношение. Словом «поколение» выражается лишь общие тендении и абстрактность языковых терминов. Даже в наши дни до сих пор создаются языки «младших» поколений, для решения каких либо конкретных задач, если для этого есть предпосылки.

Языком первого поколения является машинный код. Он и сейчас используется, в него в конечном итоге транслируют все другие языки программировния. Молодежь может быть не в курсе, но еще лет 30-40 тому назад на нем писали живые люди. Кроме шуток. Не хакеры, а прикладные программисты. Прямо так байтик по байтику составляли прикладные программы, например расчет зарплаты сотрудникам завода.

Наиболее известный представитель второго поколения — Ассемблер (ASM). С помощью него повысилась скорость написания программ и совместимость при переносе на родственное оборудование. Ассемблер не просто привел в соответствие машинным кодам какие-то мнемонические команды, а позволил абстрагироваться от многих технических деталей, позволив больше сосредоточится на решении прикладной задачи. Собственно этот последний тезис является главным признаком индукции при переходе от одного поколения языка к другому.

Третье поколение языков позволило практически полностю абстрагироваться от «железа». Их уже столько много, что перечислить затруднительно. Одни из пионеров — Фортран, Паскаль, Бейсик. Языки третьего поколения до сих пор самые используемые и кажется, что покрывают все необходимые потребности современного программирования. Однако прогресс не стоит на месте. Теория программирования сделала следующий шаг и породила четвертое поколение языков (4GL).

Не каждый язык имеет ярлык конкретного поколения и свое четкое место на шкале. Примером такого является Си. Хотя Си появился, когда эра третьего поколения была уже в разгаре, но родился он с явними признаками языка второго поколения. Это нисколько не аттавизм и не деградация. Он именно таким и задумывался – язык для написания операционных систем. Взяв все необходимые новшества и синтаксические удобства языков третьего поколения, он позволяет писать программы, практически оптимизировануми также, как на Ассемблере. Можно сказать, что он находится на отметке 2 ½ поколения.

Не меннее интересна картина с С++. Синтаксически это тот же Си с дополнительными прибамбасами. Но из-за них С++ перестал быть языком. Сам по себе он не представляет бОлшей ценности, чем Си. Интересным он становится тогда, в нем создана та или иная объектная иерархия, переопределены операторы и т.п. Когда мы получаем новую концепцию работы с данными. Практически это новый язык с Си синтаксисом, который может соответствовать любому поколению. То есть по сути С++ не язык, а инструмент для создания языков. К сожалению большинство програмистов звезд с неба не хватают. Какая бы не была навороченная иерархия объектов, созданная в С++, она будет соответствовать банальному третьему поколению языков. ООП находится в полном перпендикуляре к линии повышения абстракций.

Мы сейчас живем на стыке эпох третьего и четвертого поколения. Многие просто недопонимают самого смысла появления нового поколения, при том, что старые языки так прекрасно решают все вопросы. Суть индукции следующего шага все та же — абстракция от технических деталей с целью более быстрого решения прикладной задачи.

Здесь следовало бы привести примеры языков четвертого поколения. Перед этим необходимо сделать оговорку, что упомянутые далее языки могут обладать в той или иной мере свойствами четвертого поколения. Синтаксически это может быть не выражено явно. 4GL — это новая концепция, а не новый синтаксис. Синтаксически язык может быть похож на язык третьего поколения, но подход при работе с ним будет другим.

Формально к языкам четвертого поколения можно отнести SQL. Это наиболее известный представитель, но посколько он используется в очень узкой специфической задаче, то наглядно не демонстрирует все аспекты 4GL. Одну из ранних попыток предпринял Informix. Вместе со своей базой данных и набором стандартных библиотек для других популярных языков третьего поколения, они предлагают свой собственный язык Informix-4GL. В качестве синтаксической модели они взяли SQL и дополнив другими языковыми конструкциями сделали из него полноценную среду разработки, в котором SQL команды явлются не чем-то инородным, заключенным в кавычки, а нативной частью языка. В этом смысле к языкам четвертого поколения можно отнести семейство dBase, FoxBase, Clipper и им подобные.

Внимательный читатель может заметить из нескольких перечисленных примеров, что здесь говорится даже больше не о языке, а о среде разработки. Это будет правильное замечание, поскольку современые прикладные задачи требуют баз данных, не просто как нечто, где можно сохранить кое-какие конфигурационные данные. База данных (в широком смысле этого слова) становится ядром, вокруг которого строится приложение. Поэтому не удивительно, что она уже не хочет довольствоваться правами сторонней библиотеки (бедного родственника). Из-за естественных ограничений мы получаем ситуацию, когда не к языку привязывается база данных, а вокруг какой-то конкретной реализации базы возводится язык. Универсальные решения мне пока не известны.
Для начала определимся, что понимается под «высоким уровнем»? Традиционно языки программирования разделяются на поколения. Сам термин поколения языка достаточно редко используется в русской технической литературе, да и сам язык не всегда можно четко и категорично отнести к тому или иному поколению. Поэтому давайте разберемся, сначала с ним, а потом перейдем собственно к PHP.

Поколение языка к его возрасту имеет косвенное отношение. Словом «поколение» выражается лишь общие тендении и абстрактность языковых терминов. Даже в наши дни до сих пор создаются языки «младших» поколений, для решения каких либо конкретных задач, если для этого есть предпосылки.

Языком первого поколения является машинный код. Он и сейчас используется, в него в конечном итоге транслируют все другие языки программировния. Молодежь может быть не в курсе, но еще лет 30-40 тому назад на нем писали живые люди. Кроме шуток. Не хакеры, а прикладные программисты. Прямо так байтик по байтику составляли прикладные программы, например расчет зарплаты сотрудникам завода.

Наиболее известный представитель второго поколения — Ассемблер (ASM). С помощью него повысилась скорость написания программ и совместимость при переносе на родственное оборудование. Ассемблер не просто привел в соответствие машинным кодам какие-то мнемонические команды, а позволил абстрагироваться от многих технических деталей, позволив больше сосредоточится на решении прикладной задачи. Собственно этот последний тезис является главным признаком индукции при переходе от одного поколения языка к другому.

Третье поколение языков позволило практически полностю абстрагироваться от «железа». Их уже столько много, что перечислить затруднительно. Одни из пионеров — Фортран, Паскаль, Бейсик. Языки третьего поколения до сих пор самые используемые и кажется, что покрывают все необходимые потребности современного программирования. Однако прогресс не стоит на месте. Теория программирования сделала следующий шаг и породила четвертое поколение языков (4GL).

Не каждый язык имеет ярлык конкретного поколения и свое четкое место на шкале. Примером такого является Си. Хотя Си появился, когда эра третьего поколения была уже в разгаре, но родился он с явними признаками языка второго поколения. Это нисколько не аттавизм и не деградация. Он именно таким и задумывался – язык для написания операционных систем. Взяв все необходимые новшества и синтаксические удобства языков третьего поколения, он позволяет писать программы, практически оптимизировануми также, как на Ассемблере. Можно сказать, что он находится на отметке 2 ½ поколения.

Не меннее интересна картина с С++. Синтаксически это тот же Си с дополнительными прибамбасами. Но из-за них С++ перестал быть языком. Сам по себе он не представляет бОлшей ценности, чем Си. Интересным он становится тогда, в нем создана та или иная объектная иерархия, переопределены операторы и т.п. Когда мы получаем новую концепцию работы с данными. Практически это новый язык с Си синтаксисом, который может соответствовать любому поколению. То есть по сути С++ не язык, а инструмент для создания языков. К сожалению большинство програмистов звезд с неба не хватают. Какая бы не была навороченная иерархия объектов, созданная в С++, она будет соответствовать банальному третьему поколению языков. ООП находится в полном перпендикуляре к линии повышения абстракций.

Мы сейчас живем на стыке эпох третьего и четвертого поколения. Многие просто недопонимают самого смысла появления нового поколения, при том, что старые языки так прекрасно решают все вопросы. Суть индукции следующего шага все та же — абстракция от технических деталей с целью более быстрого решения прикладной задачи.

Здесь следовало бы привести примеры языков четвертого поколения. Перед этим необходимо сделать оговорку, что упомянутые далее языки могут обладать в той или иной мере свойствами четвертого поколения. Синтаксически это может быть не выражено явно. 4GL — это новая концепция, а не новый синтаксис. Синтаксически язык может быть похож на язык третьего поколения, но подход при работе с ним будет другим.

Формально к языкам четвертого поколения можно отнести SQL. Это наиболее известный представитель, но посколько он используется в очень узкой специфической задаче, то наглядно не демонстрирует все аспекты 4GL. Одну из ранних попыток предпринял Informix. Вместе со своей базой данных и набором стандартных библиотек для других популярных языков третьего поколения, они предлагают свой собственный язык Informix-4GL. В качестве синтаксической модели они взяли SQL и дополнив другими языковыми конструкциями сделали из него полноценную среду разработки, в котором SQL команды явлются не чем-то инородным, заключенным в кавычки, а нативной частью языка. В этом смысле к языкам четвертого поколения можно отнести семейство dBase, FoxBase, Clipper и им подобные.

Внимательный читатель может заметить из нескольких перечисленных примеров, что здесь говорится даже больше не о языке, а о среде разработки. Это будет правильное замечание, поскольку современые прикладные задачи требуют баз данных, не просто как нечто, где можно сохранить кое-какие конфигурационные данные. База данных (в широком смысле этого слова) становится ядром, вокруг которого строится приложение. Поэтому не удивительно, что она уже не хочет довольствоваться правами сторонней библиотеки (бедного родственника). Из-за естественных ограничений мы получаем ситуацию, когда не к языку привязывается база данных, а вокруг какой-то конкретной реализации базы возводится язык. Универсальные решения мне пока не известны.
Разработка SDK имеет немало сложностей и требует от команды большого опыта, в этой области нужно постоянно учиться. В свою очередь, SDK помогает расширить целевую аудиторию за счет пользователей мобильных устройств и в перспективе увеличить прибыль, так что бесспорно это очень полезно для компаний
В целом — да. API — кем-то предоставляемый набор интерфейсов. ОС, кем-то в сети и т.п.

SDK — пакет который устанавливаешь себе сам для работы с этими интерфейсами.

Как пример — есть WinAPI — экспортируемые системные функции которые реализованы в ядре ОС. WinSDK — пакет для работы с этими функциями — заголовочные файлы, библиотеки импорта, оффлайновая документация.

В принципе, можно и без SDK — почитать про нужную функцию на MSDN, самому написать заголовочный файл, получить ее адрес через GetProcAddress (или самому сделать библиотеку импорта нужного модуля при помощи implib).

Но если функций много таких, то это все дополнительные затраты времени и сил.
0
То есть, главное отличие — SDK можно скачать/купить, сохранить на диск, установить (если предусмотрен инсталлятор), а API это нечто сторонее, верно?
Лично встречался со случаем когда умирающий блок питания в предсмертной агонии убил почти все комплектующие. К счастью, в тот раз одним из выживших был жёсткий диск. Прожил он, однако, после этого не долго.

Был случай, когда по вине горе-электрика выгорело множество бытовой техники в целом доме. Знаю об этом не понаслышке, т.к. учился с одним из обывателей данного многоквартирного дома. Деньги на новую технику можно попытаться высудить у управляющей компании, но потерянных данных вам никто не вернёт.

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

Многие мои знакомые (почти все) справедливо считают меня параноиком, но тем не менее бэкап я храню следующим образом:

1. Делаю версифицированный бэкап локально на отдельном жёстком диске. Версифицированность получаю следующим образом: sudo rsync -av -HAX --delete -b --backup-dir="../home--`date +%Y-%m-%d--%k-%M-%S`" /home ./backups;
2. Локальный бэкап периодически целиком переправляю в прекрасное далёко. Оно достаточно далеко для того чтобы авиационный снаряд не смог одновременно уничтожить локальный и удалённый бэкапы;
3. Файлы подлежащие «вечному» хранению делаю «бессмертными» (устанавливаю атрибут immutable на ФС etx4);
4. Периодически уничтожаю ненужные дубликаты файлов появившиеся в следствии версифицированности (с помощью незамысловатых скриптов, использующих fdupes).
Было бы интересно увидеть, скажем, решение по инкрементальному бэкапу на Amazon Glacier для Linux, понятное для домашнего пользователя. Очень хочется иметь возможность настроить «серьёзный» бэкап за минимальные деньги.
Не вопрос.

Анализируя существующую или придумывая для себя новую СРК — подумайте, соответствует ли она критериям, изложенным выше?

Пересекаются ли в одном месте основная и резервная копия? Обеспечивается ли при этом изолированность резервной? Существует ли возможность одновременно изменять файлы в основном и резервном хранилище? Существует ли значительная (более значительная, чем атомный взрыв) вероятность того, что оба носителя будут одновременно уничтожены или утеряны? Если ответ на любой из этих вопросов «да» — в системе есть ошибка. К примеру, если вы сделали бэкап файлов с ноутбука на usb flash и убрали ее в сейф — вы молодец. Если вы сделали этот бэкап и положили флешку в сумку к ноутбуку — вы не сделали бэкап.

Обеспечивает ли ваша схема целостность данных? К примеру, если на резервном носителе закончится место и копия не сможет корректно сохраниться — вы об этом узнаете?
Обеспечивает ли она полноту? Если это приложение — сохранены ли настройки, если база данных — схема и т.д.?
Можно ли из существующей копии получить работающий оригинал? Или чего-то не хватает?

Представляете ли вы себе, что будете делать, если потеряете основные данные? Есть ли (пусть простейшая) методика восстановления? Все ли ее пункты выполнимы и достаточны для получения данных? Практике известны примеры, когда бэкап делался на зашифрованный HDD, а сложный и безопасный ключ шифрования хранился не в голове у владельца и даже не на желтой бумажке, а… да-да, на том ноутбуке, откуда и делался бэкап. Как вы понимаете, при краже ноутбука данные были утрачены безвозвратно.

Проведите «учения» — представьте, что основной носитель утрачен и попытайтесь восстановиться. Уверен, с первого раза у вас ничего не выйдет, или выяснится, что многое на самом деле не совсем так, как вы представляли ранее.

Ответили? Провели? Все прекрасно? Нет, не совсем. Не забывайте о СРК. Поддерживайте ее в актуальном состоянии. Начали использовать новое ПО? Внесите его каталоги в список на бэкап. Подумайте, как его восстанавливать. Следите за состоянием резервного носителя (если это одиночный диск, флешка или NAS — он совсем не вечный). Думайте о своих данных, кроме вас этого не сделает никто.

Мифы и примеры плохих решений

Почему-то люди любят обманывать себя. Например, многие верят, что RAID заменяет бэкап и гарантирует сохранность данных. Особенно если RAID не простенький — первый, а навороченный, 5ый например.

Но RAID — не бэкап. Из определенных выше критериев в общем случае не выполняются все три — зеркальные диски не изолированы, не контролируются и не версионируются. Падение файловой системы, случайный «rm -rf /» или ошибка при работе с разделами уничтожит данные на обоих дисках и RAID ничем не поможет их сохранить. Больше того, если поврежденную FS на одном диске обычно можно восстановить хотя-бы частично, то распавшийся массив — почти всегда нет.

Распространенная схема «отдельный HDD для бэкапа» тоже нежизнеспособна. Во-первых, резервные данные доступны и уязвимы для злоумышленника, вируса или обычной ошибки на вроде вышеупомянутого «rm -rf /». Во-вторых, есть множество ситуаций, причем весьма вероятных, которые погубят одновременно оба диска. Например бурная и красивая (со спецэффектами) смерть блока питания. Или опрокинутое на компьютер уборщицей ведро воды. Или… много их.

Утилиты вроде dropbox тоже для бэкапа мало годятся — если, конечно, не предусмотрена версионируемость. Случайно испортив данные в основной копии вы потеряете и резервную, едва между ними синхронизируются изменения. Данные будет уже не вернуть.
Очень интересно Владислав, можно ближе к практике
Очень часто я слышу фразы вроде «зачем мне бэкап, у меня же есть RAID!». Или «я делаю бэкапы на второй HDD в сервере!». Или что-то подобное. Очень часто через несколько месяцев после этого я слышу вопрос «а как мне восстановить убитые данные?». И это печалит.

Логично предположить, что это копия данных, предварительно сохраненная с целью восстановления в случае уничтожения оригинала.

Отсюда вытекает первое требование — изолированность. Не имеет смысла делать копию документов на квартиру и хранить ее там же, где оригинал. Так не имеет смысла делать копию данных и хранить ее на том же диске/в том же сервере, что и оригинал. Логично? Вполне.

Едем дальше. Если мы делаем копию данных, значит, боимся их потерять. Так? Так. Значит, все резервируемые данные для нас ценны. Так? Снова так. Отсюда второе требование — целостность. Не смысла в копировании без проверки целостности — на выходе мы вполне можем получить битые данные или потерять часть безвозвратно.

Еще один пункт. Представим, что вы удалили файл. Или не файл, а много файлов. Например, случайно сделали «rm -rf ./ test». И ушли спать, со спокойной совестью. А в полночь произошел… бэкап. Но вот незадача — настроен он был так, что создавал полную копию данных без учета версий и изменений. Т.е. удалил удаленный вами файл и на резервном носителе тоже — сделал вещь, обратную своему назначению. Представили? Третье требование — версионированность. Вы должны иметь возможность вернуть предыдущее состояние своих данных, а не только иметь две одинаковые копии.

Ну и хватит, наверное. Статья ориентирована на SOHO-пользователей, а не на энтерпрайз, поэтому требования к безопасности, скорости disaster recovery, ограниченной избыточности и прочему мы рассматривать не будем.

И что в итоге?

В итоге мы получили три требования, которым должна соответствовать система резервного копирования для того, чтобы носить это гордое имя и надежно хранить ваши данные. Изолированность защитит от сбоя оборудования или внешних факторов (пожара, потопа и т.д.), а также злонамеренного удаления данных (не позволит злоумышленнику или вирусу заразить/удалить и бэкап тоже), контроль целостности гарантирует, что зарезервированы все ваши данные и вы не останетесь у разбитого корыта при утрате основного экземпляра, узнав о проблемах слишком поздно, версионированность не даст бэкап-системе переместить пулю из ноги пользователя, который прострелил себе колено — ему же в голову.
Мои основные выводы насчет нишевых маркетплейсов:
— Сейчас на рынке существует более 100 нишевых маркетплейсов;

— Нишевые маркетплейсы являются качественным дополнительным каналом продаж для предпринимателей благодаря уникальной лояльной аудитории, высокой конверсии в продажу, а также невысоким комиссиям;

— Покупатели приходят на нишевый маркетплейс за широким выбором качественных товаров определенной категории;

— Более половины респондентов выбирают нишевый маркетплейс для поиска коллекционных вещей, товаров, требующих экспертизы или ориентированных на определенные потребности или физические особенности, а также товаров для профессиональных целей.
Мои основные выводы насчет нишевых маркетплейсов:
— Сейчас на рынке существует более 100 нишевых маркетплейсов;

— Нишевые маркетплейсы являются качественным дополнительным каналом продаж для предпринимателей благодаря уникальной лояльной аудитории, высокой конверсии в продажу, а также невысоким комиссиям;

— Покупатели приходят на нишевый маркетплейс за широким выбором качественных товаров определенной категории;

— Более половины респондентов выбирают нишевый маркетплейс для поиска коллекционных вещей, товаров, требующих экспертизы или ориентированных на определенные потребности или физические особенности, а также товаров для профессиональных целей.
Мои основные выводы насчет нишевых маркетплейсов:

— Сейчас на рынке существует более 100 нишевых маркетплейсов;

— Нишевые маркетплейсы являются качественным дополнительным каналом продаж для предпринимателей благодаря уникальной лояльной аудитории, высокой конверсии в продажу, а также невысоким комиссиям;

— Покупатели приходят на нишевый маркетплейс за широким выбором качественных товаров определенной категории;

— Более половины респондентов выбирают нишевый маркетплейс для поиска коллекционных вещей, товаров, требующих экспертизы или ориентированных на определенные потребности или физические особенности, а также товаров для профессиональных целей.
Внедрение объяснимого ИИ дает ряд положительных эффектов как в коммерческом, так и в государственном секторах:

— повышение производительности, более быстрое выявление ошибок в модели;
— укрепление доверия со стороны клиентов и пользователей;
— снижение регуляторных и других рисков.

В некоторых странах внедрение объяснимого ИИ станет обязательным требованием для компаний со стороны государств. Европарламент уже принял закон под названием AI Act, который устанавливает правила и требования для разработчиков моделей ИИ. Они должны обеспечить прозрачность работы таких систем.
Перспективы внедрения XAI

Несмотря на все плюсы XAI, внедрение такого ИИ сталкивается с рядом препятствий, таких как:

отсутствие консенсуса по определениям нескольких ключевых понятий — некоторые исследователи используют термины «объяснимость» и «интерпретируемость» как синонимы, а другие четко разделяют их;
недостаток практических рекомендаций по поводу того, как выбирать, внедрять и тестировать XAI;
отсутствие понимания, должен ли объяснимый ИИ быть понятным для обычных пользователей.

Отдельные исследователи предложили идею «белого ящика», или моделей, которые будут объяснимыми и прозрачными. Так, систему ИИ можно разбивать на модули, каждый из которых может быть интерпретирован, либо изначально строить модели с соблюдением правил прозрачности, чтобы разработчик не терял контроль над ситуацией.

Однако другие эксперты считают, что и «белый ящик» не решит проблему доверия к ИИ со стороны людей, у которых нет технического образования. По их мнению, XAI и объяснимый ИИ — это лишь часть более широких усилий для создания искусственного интеллекта, работа которого будет понятна любому человеку.
ИИ используется в разработке программных решений на следующих этапах:

Сбор технических требований

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

Быстрое прототипирование

Преобразование бизнес-требований в программный код обычно занимает месяцы или даже годы. Однако машинное обучение значительно сокращает этот процесс, позволяя специалистам с меньшим опытом использовать методы разработки естественного языка или визуального интерфейса для создания прототипа.

Кодирование

В процессе написания кода, работающая на базе ИИ система автозаполнения предлагает рекомендации для завершения строчек кода. Интеллектуальные помощники сокращают время на создание кода на 50%. Дополнительно они могут рекомендовать обратиться к связанным документам, лучшим практикам и дать примеры кода.

Анализ и обработка ошибок

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

Автоматический рефакторинг кода

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

Тестирование

Автоматизированные системы тестирования используют ИИ не только для того, чтобы запускать процесс тестирования, но и для создания test кейсов.

Ввод в эксплуатацию

Иногда ошибки в программном коде становятся явными только после того, как программное обеспечение введено в эксплуатацию. Но AI-инструменты предотвращают подобные ситуации, проверяя статистику предыдущих релизов и логи приложений.

Управление проектами

Разработка программного обеспечения иногда выходит за рамки бюджета и графика. Системы продвинутой аналитики позволяют использовать данные большого количества проектов по разработке ПО для прогнозирования технических задач, необходимых ресурсов и времени на выполнение проекта. Машинное обучение может извлекать данные из прошлых проектов, такие как истории пользователей, определения функций, оценки и фактические условия, для более точного прогнозирования рабочей нагрузки и бюджета.
Хотелось бы подробней узнать про конкретные области применения искусственного интеллекта при разработке ПО, на каких этапах и какие инструменты
ИИ используется в разработке программных решений на следующих этапах:

Сбор технических требований

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

Быстрое прототипирование

Преобразование бизнес-требований в программный код обычно занимает месяцы или даже годы. Однако машинное обучение значительно сокращает этот процесс, позволяя специалистам с меньшим опытом использовать методы разработки естественного языка или визуального интерфейса для создания прототипа.

Кодирование

В процессе написания кода, работающая на базе ИИ система автозаполнения предлагает рекомендации для завершения строчек кода. Интеллектуальные помощники сокращают время на создание кода на 50%. Дополнительно они могут рекомендовать обратиться к связанным документам, лучшим практикам и дать примеры кода.

Анализ и обработка ошибок

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

Автоматический рефакторинг кода

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

Тестирование

Автоматизированные системы тестирования используют ИИ не только для того, чтобы запускать процесс тестирования, но и для создания test кейсов.

Ввод в эксплуатацию

Иногда ошибки в программном коде становятся явными только после того, как программное обеспечение введено в эксплуатацию. Но AI-инструменты предотвращают подобные ситуации, проверяя статистику предыдущих релизов и логи приложений.

Управление проектами

Разработка программного обеспечения иногда выходит за рамки бюджета и графика. Системы продвинутой аналитики позволяют использовать данные большого количества проектов по разработке ПО для прогнозирования технических задач, необходимых ресурсов и времени на выполнение проекта. Машинное обучение может извлекать данные из прошлых проектов, такие как истории пользователей, определения функций, оценки и фактические условия, для более точного прогнозирования рабочей нагрузки и бюджета.