Pull to refresh
62
0
Андрей Николаев @Dremkin

User

Как мнение: То, что можно продать, должно лежать в одной таблице и иметь свой id. То, что программистам лень/не удобно/долго добавлять множество свойств товара - это проблема программистов, а не структуры данных. Задача с множествами размеров, цветов и тд решается простым id_parent на себя саму. Это решает множество проблем при учёте товаров в бухгалтерии, экспорте, импорте и тп. Хранение же данных в json можно рассмотреть как вариант кеширования.

Не думали забросить программирование и просто стать писателем? У вас отлично получается, можно попробовать что-то художественное )

А потом искать фромы на страницах справа? )

Я в своей системе сделал локальный сервер. Пользуюсь больше 5 лет, всякое бывало )) много раз перелазил через забор, т.к. ворота не открывались) но это все ерунда, ничего критичного. И вот я пришел к выводу, что без управления с инета можно спокойно пережить какое-то время, главное - продублировать функции через физические кнопки (у меня кнопки могут нажиматься от 1 до n - и выполняются определенные действия).

1.1. Для внутренней системы погружение в материал очень полезно. После приема на работу это отдельный курс по повышению квалификации :) Да и ссылку можно запомнить для будущего применения.. Для внешних клиентов это наоборот вредно (да и невозможно).

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

  1. Здесь согласен - интерактив, если он реально полезен, очень большое преимущество. С другой стороны и в wiki можно встроить скрипт по запуску чего-либо.

Еще стоит учесть, что создание и обслуживание подобного супербота гораздо более ресурсоемкая вещь, чем ведение wiki.

Можете ради интереса сформулировать чем выгодно отличается хорошо оформленная внутренняя wiki от такого супер бота? Ведь в конечном счёте у вас это просто вопрос поиска нужной информации.

Похоже стёб никто не понял :)

Я Хабр просматриваю раз в 3 недели, трачу на это 10 минут, черпаю иногда очень интересное для работы, так что время на "чтение всяких статеек" окупается в степени :) Сериалы, кстати, не смотрю. И водку не пью (сообщаю, ибо предвкушаю ваш следующий аргумент :)

Очень круто, но и очень жалко время автора на это :)

Если вы скажете что-то типа "я не запоминаю синтаксис, а решаю задачи" и после этого вас выгонят, то собеседование для вас прошло успешно )

Это к вопросу фич - вы просто делаете работу или достигаете какой-то цели. Нужно было сделать какой-то график - работа выполнена красиво )

Ок, уволите меня, если вдруг станете моим начальником :)

"Но не в этом дело" вы похоже пропустили, ну ладно. Сейчас мы дойдем до того, что ООП нужно для автодополнения в IDE. Я вот не программировал в IDE уже лет 15 - вот такая неказиста жизнь простого программиста :)

article_set($id_article, ["meta"=>'', "title"=>'', "body"=>'']);

Ну и множество других вариантов как решить проблему. Но не в этом дело. Сохранение подразумевается по умолчанию.. не переписывать же сервер БД на клиенте :)

В случае отправки id сохранение в базе подразумевается в примерно 98% случаев ) Хотя конечно могут быть варианты. Но и с объектом тоже не так сложно - достаточно один раз ознакомиться с шаблоном проектирования

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

Судить здесь можно либо материал, либо автора. Первое - сложно и долго, второе проще простого, особенно на аналогиях.

Скорее всего не будет там репутационного урона - заказы как были, так и продолжат поступать, это же НЕ конкурентная среда.

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

Information

Rating
3,450-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity