Правда?
Мой папа, поколения 50+, программировал контроллеры лабораторных печей на asm-е, будучи металлургом физхимиком. Фидошники чуть меньше чем все 30+. Тетрис придумал русский 56г рождения.
Поколение здесь вообще не причем.
На гробнице фараона 5,5 тысяч лет назад была сделана надпись: «Молодые строптивы, без послушания и уважения к старшим. Истину отбросили, обычаев не признают. Никто их не понимает, и они не хотят, чтобы их понимали. Несут миру погибель и станут последним его пределом».
Ничего не изменилось, и не измениться.
Может просто ума не хватает? И виновата здесь грамотность в общем, а не компьютерная в частности.
Кто кроме научников занимается самообразованием после 30 лет?
Для ruby более чем реально.
В руби все объект, у каждого объекта есть метод methods, который возвращает список доступных объекту методов. Т.о. автокомплит встроен в среду.
Что касается Ruby on Rails, то ситуация аналогичная. Использовать встроенный в фреймворк автокомплит в IDE(если ее рассматривать как надстройку над фреймворком) не должно составить труда
Для примера
>> User.first.id_ #тут я кликнул по табу два раза
User.first.id_before_type_cast
User.first.id_changed?
User.first.id_constraint?
User.first.id_partition
User.first.id_was
User.first.id_change
User.first.id_constraint
User.first.id_left
User.first.id_right
User.first.id_will_change!
Завтра-послезавтра, кто-нибудь сядет и напишет автокомплит для sublime text 2
Макконнелл возможно, в чем-то, и прав. Я согласен делать это только подсознательно.
Тесты с этим справляются эффективнее. Да и TDD пока никто не отменил.
Я так и не понял чем плох REST. Не вижу разницы между:
host.ru/api + {«jsonrpc»: «2.0», «method»: «sum», «params»: [1,2,4], «id»: «1»}
и
get: host.ru/sum/1.json + {«params»:[1,2,4]}
И если вы изначально пишите RESTfull приложение вопрос об изобретении API над рабочим приложением отпадает сам собой. Тестировать вам приходится только свое приложение и писать изменения только в приложение. И курить левую документацию к левой софтине нет никакой необходимости.
Вы же предлагаете следующий сценарий:
1. Подключить API
2. обложить тестами API
Когда требуются изменения:
3. Писать тесты для app
4. Писать код в app (или наоборот)
5. Писать тесты для API
6. Писать код в API (или наоборот)
Когда в классической схеме RESTfull
1. пишем тест
2. пишем код
(или наоборот)
Завтра уже наступило, как мне кажется. Лично вот я, видимо, просто по инерции не способен это осознать. А этот факт неуклонно ведет к стандартизации средств бэкапа всей! системы в облака. Тем более, что, как минимум, Apple показал мне, как это можно сделать хорошо. Amazon Simple Storage стоит 0.12 центов за гиг. Терабайт таким образом обойдется в 12.5$ в месяц. В год — сумма сопоставимая со стоимостью «домашней» хранилки, которая не обеспечивает такого уровня устойчивости как Amazon. Это не реклама Amazon, это одно из решений.
Что касается сотни гигабайт новых данных — редчайший случай, я с трудом могу представить себе систему способную генерировать сотни гигабайт данных. Мультимедиа? Для решения подобных задач строятся приватные облака. А это датацентры. Ведь если эти данные оперативные, то их какбэ не совсем бэкапят, их зеркалируют. Если это данные которые необходимы в течении скажем, года, то это уже сотни терабайт в год. Если эти данные обладают повышенной важностью, то на физическом уровне их важно хранить в территориально распределенных датацентрах, лучше даже разных стран.
Облака частично решают чуть меньше, чем все эти проблемы. Исключением могут быть только случаи с большими объемами данных — интернеты не резиновые… пока.
Я был в крайней степени удивлен, когда после полного сброса в заводские настройки(ремонт после физического повреждения) мой айпад благополучно произвел реинкарнацию. Новую инкарнацию от старой я отличить не смог. Весь процесс занял меньше часа рабочего времени айпада, я, в свою очередь, благодушно предавался чревоугодию и иной фигне, не отнесенной к смертным грехам и, как следствие, на восстановление данных не потратил времени.
Покуда в пресслужбах крупных государственных структур будут сидеть блатные блондинки… О чем я говорю?.. Пресслужбы занимаются освещением действий руководителей, и отмазками. Пичалька, злостька и гневик (ц)
Соискатель — товар, наниматель — покупатель. Процесс продажи соискателя нанимателю ничем не отличается от продажи сотового телефона или компьютера. В ряде случаев наниматель не понимает, что конкретно он хочет приобрести. В ряде случаев соискатель не понимает, сколько он стоит.
Мне повезло, я всю молодость занимался продажами. То компьютеров покупателям, то различных решений заказчикам и руководителям. Важно понимать: когда перед вами ставят задачу — вы продаете решение. Трудовой договор является соглашением на длительную поставку товаров и услуг.
А приемы у каждого продавца свои. Есть общие принципы, которые можно почерпнуть из любой более-менее серьезной литературы по продажам. И это не будет лишними, ненужными знаниями для программиста. У программистов не может быть лишних знаний :)
Мой папа, поколения 50+, программировал контроллеры лабораторных печей на asm-е, будучи металлургом физхимиком. Фидошники чуть меньше чем все 30+. Тетрис придумал русский 56г рождения.
Поколение здесь вообще не причем.
На гробнице фараона 5,5 тысяч лет назад была сделана надпись: «Молодые строптивы, без послушания и уважения к старшим. Истину отбросили, обычаев не признают. Никто их не понимает, и они не хотят, чтобы их понимали. Несут миру погибель и станут последним его пределом».
Ничего не изменилось, и не измениться.
Может просто ума не хватает? И виновата здесь грамотность в общем, а не компьютерная в частности.
Кто кроме научников занимается самообразованием после 30 лет?
В руби все объект, у каждого объекта есть метод methods, который возвращает список доступных объекту методов. Т.о. автокомплит встроен в среду.
Что касается Ruby on Rails, то ситуация аналогичная. Использовать встроенный в фреймворк автокомплит в IDE(если ее рассматривать как надстройку над фреймворком) не должно составить труда
Для примера
Завтра-послезавтра, кто-нибудь сядет и напишет автокомплит для sublime text 2
Другой пример:
Так вроде Yii уже умеет это, нет?
Тесты с этим справляются эффективнее. Да и TDD пока никто не отменил.
* auto-discovery — захватывает все public методы класса? куда девать public методы не используемые в API?
* mass-assignment?
host.ru/api + {«jsonrpc»: «2.0», «method»: «sum», «params»: [1,2,4], «id»: «1»}
и
get: host.ru/sum/1.json + {«params»:[1,2,4]}
И если вы изначально пишите RESTfull приложение вопрос об изобретении API над рабочим приложением отпадает сам собой. Тестировать вам приходится только свое приложение и писать изменения только в приложение. И курить левую документацию к левой софтине нет никакой необходимости.
Вы же предлагаете следующий сценарий:
1. Подключить API
2. обложить тестами API
Когда требуются изменения:
3. Писать тесты для app
4. Писать код в app (или наоборот)
5. Писать тесты для API
6. Писать код в API (или наоборот)
Когда в классической схеме RESTfull
1. пишем тест
2. пишем код
(или наоборот)
Что касается сотни гигабайт новых данных — редчайший случай, я с трудом могу представить себе систему способную генерировать сотни гигабайт данных. Мультимедиа? Для решения подобных задач строятся приватные облака. А это датацентры. Ведь если эти данные оперативные, то их какбэ не совсем бэкапят, их зеркалируют. Если это данные которые необходимы в течении скажем, года, то это уже сотни терабайт в год. Если эти данные обладают повышенной важностью, то на физическом уровне их важно хранить в территориально распределенных датацентрах, лучше даже разных стран.
Я был в крайней степени удивлен, когда после полного сброса в заводские настройки(ремонт после физического повреждения) мой айпад благополучно произвел реинкарнацию. Новую инкарнацию от старой я отличить не смог. Весь процесс занял меньше часа рабочего времени айпада, я, в свою очередь, благодушно предавался чревоугодию и иной фигне, не отнесенной к смертным грехам и, как следствие, на восстановление данных не потратил времени.
Мне повезло, я всю молодость занимался продажами. То компьютеров покупателям, то различных решений заказчикам и руководителям. Важно понимать: когда перед вами ставят задачу — вы продаете решение. Трудовой договор является соглашением на длительную поставку товаров и услуг.
А приемы у каждого продавца свои. Есть общие принципы, которые можно почерпнуть из любой более-менее серьезной литературы по продажам. И это не будет лишними, ненужными знаниями для программиста. У программистов не может быть лишних знаний :)