Проверь себя - развлечение

Придумалась вот такая штука - по самому простому приложению типа "Hello, world !" задать много вопросов. Вот что получилось:

package edu.javacourse.hello;


public class Hello
{
    public static void main(String[] args) {
        System.out.println("Hello, world !");
    }
}

И опять про опыт использования и изучение инструментов

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

Опять про опыт использования

Читая форумы регулярно возникает ощущение, что начинающим программистам очень важна технология, которая (как им кажется) резко повысит их уровень при приеме на работу. Отчасти это так - знание  широко используемых инструментов является важным. Но почему-то часто за рамками остается такой крайне важный вопрос, как опыт использования. Мало уметь просто хорошо забивать гвозди - следующим (и крайне важным) шагом является понимание КУДА эти гвозди надо забивать.

Программирование - это искусство ?

Нередко встречал мнение, что программирование - искусство. Подозреваю, что родилось оно из-за достаточно известной книги Кнута "Искусство программирования". Появилось желание порассуждать на эту тему, чем и займусь.

Курсы - нужны ли они ?

Т.к. я сам веду курсы, то данная заметка наверно несколько субъективна, но тем не менее постараюсь написать честно плюсы и минусы курсов.

Практикуйтесь

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

НЕ ЖДИТЕ ЧУДА. Это равносильно считать, что чтение книг по тренировке пресса позволит вам иметь кубики на животе. Умственная деятельность требует тренировки не меньше, а возможно и больше. Пишите код, заставляйте его делать то, что вы хотите, сталкивайтесь с трудностями и решайте их. Ошибайтесь. Опыт работы вам никто не расскажет - его надо нарабатывать самому, как кубики на животе. И чем раньше вы начнете это делать, осознавая, что иначе никак - тем будет лучше для вас. Удачи.

Не обманывайте себя

Вспомнился китайский автор Лу Синь:
"А-лянь уже бежал ему навстречу, а подбежав, почтительно вытянулся, опустив руки по швам, и воскликнул:
— Учитель! — После чего продолжал с легким раздражением: — Я отказался работать. У них слово расходится с делом: обещали тысячу мер проса, а дали пятьсот. Я вынужден был уйти.
— А если бы тебе дали не тысячу, а больше, ты бы тоже ушел?
— Нет, — ответил А-лянь.
— Значит, причина не в том, что слово расходится с делом, — просто тебе мало дали!"

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

Решайте задачу

Крайне часто, читая вопросы на форумах, на память приходит история из учебника английского языка - диалог двух студентов:
- Как по-английски будет "у" ?
- Зачем тебе ?
- Хочу написать фразу "У студента нет денег"

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

Поэтому для начала постарайтесь увидеть задачу "с высоты птичьего полета". Вам необходимо сначала понять, ЧТО надо сделать, а не КАКИМ ОБРАЗОМ. Вот когда точно поймете - тогда уже выбирайте решение и задавайте вопросы для его реализации.
Вполне может быть, что для начала лучше узнать варианты решения - и для этого надо хорошо описать, ЧТО вы хотите получить. Удачи.

Прочувствовать инструмент

Постоянно убеждаюсь в таком факте - не надо изучать инструмент (технология/пакет/библиотека) ради самого инструмента. Изучайте ради решения задачи. Пусть даже пока она вас не заботит, но задача должна как минимум выглядеть реальной (лучше конечно, чтобы была реальной).
Это своеобразная трактовка изречения: "Практика - критерий истины".
Если не указано, для какой задачи применим инструмент - не нужен этот инструмент.
Если при попытке решить задачу инструмент "выкидывает коники" - не нужен этот инструмент. Но идея такого инструмента уже может быть ценной.

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

Сомнения в примерах

Все-таки зацепило :) В процессе жаркого разговора я понял, что не всегда получается донести следующую мысль - для меня важно определить в демонстрации какой-то идеи самую суть и я сознательно (в какой-то степени) игнорирую возможно интересные (и даже существенные) моменты.

Инструменты и задачи

Задумался :) Когда-то давно на лекции по экономике нам говорили о производстве средств для производства средств производства и производства средств для производства средств потребления. Если переиначить - кто-то создает станки для производства станков, а кто-то  станки для производства мороженого.

В программировании это тоже можно увидеть - кто-то создает сервера приложений, библиотеки (Spring, Struts, GWT, Drools, jBPM), а кто-то пользуется этими средствами для создания потребительских систем.

SQL vs NoSQL

Как сказал Маяковский: "Если звезды зажигают - значит это кому-нибудь нужно".
Действительно ли нужны NoSQL в таких количествах, как об этом сейчас говорят или это очередной всплеск, который утихнет и возможно погаснет совсем ?

Выбор инструментов и сложность программ

Опять я про инструментарий программиста и задачи. Как определить, что надо выбрать для конкретного проекта и где заканчивается возможность управлять сложностью задачи ?

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

Но когда только формулировка требований является весьма сложной задачей, да и сам инструмент тоже требует на изучение иногда несколько недель или месяцев - тогда как выбирать ?

Что надо знать начинающему программисту

Предварительные слова сказаны (я имею в виду статью Что надо изучать перед программированием), так что пора попробовать описать те инструменты, которые на мой взгляд, нужны программисту.

В принципе вряд ли подготовка программиста сильн оотличается от подготовки инженера - не факт, что все изученное вам пригодится и не факт, что вам не придется изучать что-то совсем новое (тут скорее ответ "придется однозначно"). Но тем не менее есть несколько областей, которые надо знать в любом случае.

Стандартные инструменты против уникальных

Вопрос в общем-то достаточно нужный и в тоже время неопределенный, но для меня "царапающий мозг". Вот и покопаемся :)

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