Способ научиться очень прост — желание и терпение. Лучше всего начинать с тренажоров для выработки привычки использования нужных пальцев в нужных местах (а то ведь можно и двумя пальцами вслепую печатать, но скорость совсем не та). А потом постояная практика. Только так. Сначала очень некомфортно и может быть много ошибок, но несмотря ни на что, нужно заставлять себя не подглядывать в клавиатуру. В принципе, при должном усердии вполне можно освоить за месяц, а через 3 уже совсем свободно печатать.
В наше время повсеместной компьютеризации это важно для любого человека, а не только для секретарши, и уж тем более важно для программиста. Если сравнить с «докомпьютерной» эрой, то слепая печать — это быстрое слитное письмо, а смотреть на клавиатуру — это медленно выводить печатные буквы, подглядывая в азбуку.
А по вашему если выкладываешь бесплатно в общий доступ, то можно плюнуть потенциальным потребителям своего продукта в лицо и добавить «скажите спасибо, что вообще выложил»? Есть определенные стандарты, заложенные сообществом, и не соблюсти их даже по-минимуму — это показать прямое неуважение. Такой продукт не внушает никакого доверия и надежды на дальнейшую поддержку. Если автор не удосужился даже первую версию сделать с человеческим лицом, то последующие будут не лучше, если вообще будут. Кому такое надо?
Ну и плюс личная непереносимость непрофессионализма, такой вот недостаток.
Как-то в мире Ruby вроде не принято выкладывать в паблик либы без единого теста, да еще и с какой-то шаблонной чушью в папке config. Неужеле сложно было оформить по-человечески?
Ну зачем же так грубо? JRuby актуален для проектов выше среднего и для него нужно минимум 1 Gb RAM, в то время как MRI прекрасно подходит для маленьких проектов и позволяет легко обходиться начальными тарифами VDS.
Перевод, к сожалению, исключительно ужасен и каверкает смысл чуть ли не каждой фразы совершенно диким образом. А о «литературности» и речи не идет… вы так и в жизни предложения строите? Не говоря уже о том, что перевод зачем-то выполнен от женского лица.
Ну, во-первых: набор у лего с кубиками полно. Покупай не хочу.
Не знал, спасибо за ссылку. Только вот в магазинах таких наборов практически нет, по крайней мере я не видел в России.
Да, сначала дети собирают по инструкции. А потом придумывают свое.
Не знаю как современные дети, но у меня у конструкторов не было никаких инструкций и в этом была их прелесть. К тому же, чтобы собирать по инструкции дети должны как минимум уже читать :)
А мне кажется, что сейчас чудовищно не хватает «бессюжетных» конструкторов. Не понять мне что может быть интересного в сборке кубиков по инструкции. Причем деталей обычно мало и они имеют нестандартную форму ровно для сборки сюжета, что-то другое из них собрать уже сложно. Как это развивает креативность и нестандартный взгляд на вещи? Такими наборами только будущего рабочего на конвейерной линии можно вырастить. Хороши они разве что для коллекционеров, но чтобы Лего был интересен детям — его надо десятками наборов покупать, для наращивания разнообразных деталей, а это уже очень не бюджетно получается.
Вот за видео — огромное спасибо. Русские конференции почему-то славяться полным отсутствием видео, поэтому если пропустил, то все — в пролете. Реально не ожидал даже, еще раз спасибо за видео и презентации!
Вроде красиво все, но как-то очень «корпоративно» что ли. Экономия видна невооруженным взглядом: столы маленькие (как уже отметили в комментарии выше), мониторы и клавиатуры дешевые, кресла вообще убили — не представляю как на таком можно 8 часов отсиживать. Не вдохновляет в общем, обычнейший офис, особенно на фоне других IT-компаний.
Ок, т.е. все сводится к тому, что мы делаем все тоже самое, только отдаем данные по кускам? Как это кардинально меняет то, что написано в статье, не понимаю. Не надо делать выборку из базы только с нужными полями? Да нет, вроде как надо. Не надо использовать хэши вместо объектов ActiveRecord? Да нет, вроде не лишняя операция. Не стоит использовать альтернативные дамперы JSON? Возможно, но нужно тестить.
В сухом остатке — вся та же самая подготовка данных, но отдача стримингом. Так? Не совсем понятно зачем мы это так долго обсуждали :)
HTTP — это протокол, а принимающая сторона — ПО, поэтому протокол может быть и поддерживает, а вот принимающая сторона может и не поддерживать. Иначе откуда взялись костыли вроде Long polling и иже с ним для браузеров?
Вообще-то, с точки зрения «моментальности» ничего не меняется — как вам БД отдавала данные по определенным критериям, так и отдает. Вопрос только в том, как и когда вы начинаете их обрабатывать.
Вообще-то, очень даже меняется. Если данные в базе изменяются, например, 20 раз в секунду, то один запрос и 1000 запросов вернут совсем разные значения.
Такое решение тоже имеет право на жизнь, но превносит дополнительную сложность, как минимум. Во-первых, принимающая сторона тоже должна поддерживать стриминг. Во-вторых, это теория, а чтобы узнать что быстрее — нужны цифры из тестов. В-третьих, может стоять задача сделать моментальный снимок данных и тянуть данные по одной записи нельзя.
Ситуация бывают разные, поэтому и решения могут быть разными. Я не утверждаю, что решение в статье, которую я перевел, подходит всем. Но и стриминг не является в данном случае 100% альтернативой, которая будет лучшей заменой для любой подобной задачи, верно?
Здесь «производительность» измеряется во времени, поэтому как затраты не «размазывай» — времени меньше не потратится. Есть задача — отдать 10 тысяч объектов и сделать это максимально быстро. Чем поможет стриминг?
Ну и плюс личная непереносимость непрофессионализма, такой вот недостаток.
Не знал, спасибо за ссылку. Только вот в магазинах таких наборов практически нет, по крайней мере я не видел в России.
Не знаю как современные дети, но у меня у конструкторов не было никаких инструкций и в этом была их прелесть. К тому же, чтобы собирать по инструкции дети должны как минимум уже читать :)
В сухом остатке — вся та же самая подготовка данных, но отдача стримингом. Так? Не совсем понятно зачем мы это так долго обсуждали :)
HTTP — это протокол, а принимающая сторона — ПО, поэтому протокол может быть и поддерживает, а вот принимающая сторона может и не поддерживать. Иначе откуда взялись костыли вроде Long polling и иже с ним для браузеров?
Вообще-то, очень даже меняется. Если данные в базе изменяются, например, 20 раз в секунду, то один запрос и 1000 запросов вернут совсем разные значения.
Привносит минимум.
Ситуация бывают разные, поэтому и решения могут быть разными. Я не утверждаю, что решение в статье, которую я перевел, подходит всем. Но и стриминг не является в данном случае 100% альтернативой, которая будет лучшей заменой для любой подобной задачи, верно?