Станислав Б, законодательство и здравый смысл мне подсказывает, что есть понятие "Чувствительные данные третьих лиц". Это когда сторона со стороны пользователя получает данные к примеру Пети, который хранит Вася. При этом Петя в какой-то момент понимает, что ничего такого не подразумевал и перестал вдуплять, что происходит, то Вася получит. Если Петя хранил данные на кудахтере Васи с соглашением, что только Петя получит эти данные, то когда Вова получает каким-то магических способом данные Пети, то Вова и Вася получат. А вот если Вася такой Вася и по ошибке открыл доступ на свои чувствительные данные, то никто не получит, но горечь от осознания такой ошибки может повергнуть Васю в уныние и он просто от обиды подаст в ментовку и вы получите.
Расскажи человеку и он забудет.
Научи человека и он запомнит.
Дай ему попробовать и он научится.
Т.е. амперка максимум даст знания, чтобы человек запомнил. Если человек не может самостоятельно найти решение, то он слаб и толку с него не будет. Нуда, получится еще один ремесленник, но толку с него.
Короче ищущий всегда найдет. Ведь есть и вторая притча.
Никита Паскал, видите, они уже подавляют вашу волю. Ох уж эти ИПешники с их дырявой лодкой и сумасшедшим пиратом Говорите, чтобы они еще подождали. За два дня не облезут, вы все же в 21 веке. Но вообще если в корпорации обещают больше, то я бы на них больше надеялся. И я так понимаю, что вы уже у них там проходите то ли стажировку, то ли что еще? Поэтому точно не соскочат, а если соскочат, то Нерон Лордов правильно сказал.
Вот блин, так и знал, что не надо указывать CRUD в пример)
Вообще я про scaffolding господин Kirill Mokevnin слышал и пользуюсь, но это скорее заранее подготовленная заготовка и может покрыть задачи что-то по типу "скелет приложения". Мне нужно в реальном времени, а не через интерфейс там что-то накликивать. Должно работать внутри кода.
Я хотел выяснить и почерпнуть более интересную технологию. Так получается, что у рядового программиста, а я занимаюсь веб-программированием в основном тривиальные проблемы и тривиальные решения. Конечно приходится подумать, почитать и разобраться как устроен текущий алгоритм того или иного функционала. При этом если мы к примеру пишем функционал по поставке-доставке инфо в API, то это просто программа-грузчик и ничего там такого нет. Сделать curl, try...catch и пару классов на шифровку и дешифровку структуры данных.
У меня лично на такое больше половины времени уходит просто на набивание кода, даже мозги не работают, но почему-то устают все равно. Забавно.
Можно конечно попробовать воспользоваться Emmet/Макросы для набития шаблонных кодов. Проблема в том, что та или иная система написана в соответствующем стилей и алгоритмической парадигме, а на каждую такую систему шаблонов не напасешься. Не знаю как у фрилансеров, но даже в своей знакомой системе придется потрудиться чтобы выяснить как лучше всего шаблоны накидать.
Вот собственно я и ищу решение своей проблемы. Как накодить приложение, чтобы меньше кодить :)
m0nym, не соглашусь. Мне вот нравится к примеру (не знаю, но наверное похоже) в PHPStorm подсветка входящих параметров для функции и подсказки возможных функций.
Вы не представляете как помогают подсказки возможных функций, а вы это поймете когда будете работать над закрытым коммерческим продуктом у которого и документации толком особо нет. Нет я не спорю, есть она в виде как это работает, но для программиста она мало чем поможет.
Подсветка неиспользуемых импортов в файле. Оно вам надо в ручную это делать?
Moskus, спасибо за наводку. Все равно в итоге немного повозился и определял как лучше строить меню. Оказывается можно и воспользоваться встроенными toc.
viktor_aksyonov, то на чем написано приложение не сильно кого-то волнует. Если приложение имеет те же функции что и раньше, то можете смело выкатывать поверх старого.
