Очень понравилось вступление про собеседования, ООП и шаблоны программирования, но как только скатились в заголовок, то и остались в нем без пояснения ради чего все это...
здесь не будет сложных технических термиов, а текст, который сможет понять совершенно не подготовленный человек
Фреймворк, jQuery, git, пулреквест, деплой... Неподготовленного такой набор неизвестных терминов, точно запутает от отпугнет от ИТ сферы.
Не стоит забывать в что в нашем мире разрабатывают не только ПО, от того разработчик === программист. В свою очередь процесс описания Архитектуры ПО (схемы документация без строчки кода) это тоже непосредственно участие в Разработке ПО. Программирование же ПО это лишь один из видов деятельности разработки ПО.
Хорошо бы упростить описание некоторых терминов, а некоторые технические блоки можно безболезненно убрать
Статья действительно сыровата. Но есть интересные мысли которыми автор очень спешил поделиться. Мне идея зашла и хочется сделать небольшой разбор. Заголовок цепляет аудиторию далекую от знаний ЯП, но в начале читателя засыпают сложными техническими терминами с делениями языков на уровни с поверхностными пояснениями сложности и ответственности работы с ними. Для целевой аудитории можно было ограничится высокоуровневыми ЯП учитывая что с БД работают именно они.
Скриптовые языки предназначены для автоматизации задач, управления программами и обработки данных. Обычно они интерпретируемые — это означает, что код выполняется напрямую без предварительной компиляции. Из‑за отсутствия компиляции такие языки могут содержать больше ошибок и выполняться медленнее, чем системные. Ответственность разработчика уже не в контроле ресурсов, а в качестве написанного кода. Может показаться, что порог входа в такие языки ниже, чем в системные. Однако, большое количество абстракций в языке требует большего времени на его изучение.
Как итог целевая аудитория вероятно закрыла статью от сложностей описаных в начале. Остались те, кто от столь громкого заголовка и захода со стороны низкоуровневых языков начали ждать соответствующего финала.
Финала по моему мнению не состоялось. Так как толком даже не была установлена связь между программированием и работой с данными и тем более сложно структурированными данными (необязательно полученными средствами SQL).
Так вот, стоило, пожалуй, рассказать о том, что многие (не все) разработчики сталкиваются с необходимостью взаимодействовать с большими объемами данных и их обработкой. О том, что данный за частую имеют между собой сложные связи. И вот тут одна из причин, почему работать с данными может быть отдельным (первым) шагом на пути к программированию.
Вот теперь можно говорить о том такие данные приходится как‑то держать в постоянной памяти и дать объяснение когда для этого используют БД и что отличает реляционные от не реляционных. И тогда читатель возможно сможет понять что такое SQL (расшифровку тоже не мешало добавить) и для чего используют.
Далее нужны примеры с данными которые могли бы увлечь не посвященных людей. Например кусок БД с комментариями к этому посту: можно выбрать только пользователей можно взять комментарии упорядочить по оценке А можно сделать сложную структуру с привязкой рейтинга пользователя, но тут возможно стоит упомянуть о транзакциях и непостоянности данных в процессах работы с данными.
Вот после этого я бы поверил, что SQL это язык и хорошее знание его принципов взаимодействия с данными даст жирный плюс в работе с данными в любом другом ЯП
Идея понравилась, но в целевую аудиторию явно не попала!
Очень понравилось вступление про собеседования, ООП и шаблоны программирования, но как только скатились в заголовок, то и остались в нем без пояснения ради чего все это...
Фреймворк, jQuery, git, пулреквест, деплой... Неподготовленного такой набор неизвестных терминов, точно запутает от отпугнет от ИТ сферы.
Не стоит забывать в что в нашем мире разрабатывают не только ПО, от того разработчик === программист. В свою очередь процесс описания Архитектуры ПО (схемы документация без строчки кода) это тоже непосредственно участие в Разработке ПО. Программирование же ПО это лишь один из видов деятельности разработки ПО.
Хорошо бы упростить описание некоторых терминов, а некоторые технические блоки можно безболезненно убрать
Статья действительно сыровата. Но есть интересные мысли которыми автор очень спешил поделиться. Мне идея зашла и хочется сделать небольшой разбор.
Заголовок цепляет аудиторию далекую от знаний ЯП, но в начале читателя засыпают сложными техническими терминами с делениями языков на уровни с поверхностными пояснениями сложности и ответственности работы с ними.
Для целевой аудитории можно было ограничится высокоуровневыми ЯП учитывая что с БД работают именно они.
Как итог целевая аудитория вероятно закрыла статью от сложностей описаных в начале.
Остались те, кто от столь громкого заголовка и захода со стороны низкоуровневых языков начали ждать соответствующего финала.
Финала по моему мнению не состоялось. Так как толком даже не была установлена связь между программированием и работой с данными и тем более сложно структурированными данными (необязательно полученными средствами SQL).
Так вот, стоило, пожалуй, рассказать о том, что многие (не все) разработчики сталкиваются с необходимостью взаимодействовать с большими объемами данных и их обработкой. О том, что данный за частую имеют между собой сложные связи. И вот тут одна из причин, почему работать с данными может быть отдельным (первым) шагом на пути к программированию.
Вот теперь можно говорить о том такие данные приходится как‑то держать в постоянной памяти и дать объяснение когда для этого используют БД и что отличает реляционные от не реляционных. И тогда читатель возможно сможет понять что такое SQL (расшифровку тоже не мешало добавить) и для чего используют.
Далее нужны примеры с данными которые могли бы увлечь не посвященных людей.
Например кусок БД с комментариями к этому посту:
можно выбрать только пользователей
можно взять комментарии упорядочить по оценке
А можно сделать сложную структуру с привязкой рейтинга пользователя, но тут возможно стоит упомянуть о транзакциях и непостоянности данных в процессах работы с данными.
Вот после этого я бы поверил, что SQL это язык и хорошее знание его принципов взаимодействия с данными даст жирный плюс в работе с данными в любом другом ЯП
Идея понравилась, но в целевую аудиторию явно не попала!
Сам я JS-ер, но сейчас дочери помогаю в проектах по изучению Python в связке с телеграм ботами.
Так вот у меня возникала такая идея:
Сделать условно админские права на бота. Если user_id из списка, то доступна команда /admin, /superadmin
По команде /superadmin получаем меню добавить/удалить админов
По команде админ получаем доступ на редактирование конфигурации
Конфигурацию можно хранить в файле json (я не даром джаваскриптер)
Админу в режиме постепенного углубления предлагают дойти до пункта меню требующего коррекции.
Далее спрашиваю, что он хочет откорректировать текст/кнопку?
Ну, а ответ админа собственно подменит это значении в файле конфигурации
Или дать возможность выгрузки текущего файла конфигурации и его загрузки после правок. Можно высылать суперадмину файл на верификацию корректности
В целом ваша статья попала для меня в актуальную тему, будет приятно если что выстрелит! Надеюсь не в ногу)