Оу, остыньте, от вас исходит какая-то непонятная агрессия. Никто не запрещает вам читать мануалы, и вы видимо очень гордитесь тем, что их читаете. В любом случае такие короткие статьи описывающие какие-то отдельные полезные функции могут очень кому-то пригодиться и сэкономить время в будущем. Если вам так нравится читать мануалы, читайте себе на здоровье)
Да при чем тут слава) Это же переводы, а не авторские статьи, я просто хочу привнести немного свежих знаний на хабру, а плюсы в карму и хороший рейтинг, это как отклик, как спасибо.
Это конечно круто, но скиллы от этого не растут, зато растет ЧСВ :)
Не правда, скиллы растут, я лично не перевожу материал, который и сам раньше знал, и перевожу исключительно то, что мне интересно. А в последнее время все больше короткие статьи перевожу, так как нет времени ввязываться в длинные переводы. Я тут как-бы просто привожу пример бессовестности хабры, а вы сразу на личности переходите.
Лично я за 7 лет ничего на хабре не написал потому, что мне нечего предложить интересного, а иногда меня опережали и публиковали схожие темы раньше.
Эм, ну знаете возьмитесь за переводы, это очень полезная вещь;)
Просто вы поймете, насколько это обидно угрохать 5 вечеров на перевод цикла статей и не получить почти никакого фидбека, а потом чисто случайно перевести коротенькую статью по джейквери и получить около 90 плюсов и кучу положительных комментариев. Я не говорю, что ваши слова не имеют веса, просто вы еще не вкусили «благодарности» хабра)
Согласитесь что заголовок «3 новых Javascript API которые вы бы могли захотеть узнать» звучит как-то инородно. И давайте вы не будете меня учить переводить. Если хотите попереводить, берите какой-нибудь пост и там упражняйтесь в правдивости
Сегодня я решил нарушить это правило и описать вам несколько API на ранней стадии разработки. Эти технологии настолько свежи, что 2 из 3 были представлены всего несколько дней назад. Поэтому они пока не могут быть использованы. Однако, если вам интересно, что они позволят сделать, вы можете почитать спецификации и написать, что бы вы хотели в них улучшить.
Согласен, но я тут поразмыслил и пришел к заключению, что от многих ошибок в таком случае спасает правильная архитектура. Если вначале проекта много времени потрачено на правильное планирование архитектуры, то потом вы все же будете ей следовать. Да, узкие места будут, кое-где будет дублирование, легкий говнокод и пр., но все же это спасет от таких вот фундаментальных ошибок. Так что, в проекте главное, чтобы был хороший тимлид для придумывания архитектуры и разруливания узких мест, и тогда график может быть сколько угодно сжатый, качество кода все-равно будет кое-как поддерживаться.
Я только за, но я пока не встречал работодателей, которые бы давали на это время. Возможно, это проблема моего личного опыта, но пока мне везде приходилось в бешеном темпе стучать по клавишам.
Очередная статья призыв писать хороший код. 90% процентов объяснения как это важно, что и само собой понятно, и несколько строк, как это может быть достигнуто.
Вы должны остановиться и оценить его читабельность и разборчивость. Читайте и перечитывайте его несколько раз. Постарайтесь отстраниться от понимания проблемы, представляя, что кто-то читает этот код без того полезного контекста, который уже есть у Вас в голове, потому что Вы пишите этот код.
Это можно делать, когда у вас куча времени. Если у программиста достаточно времени, чтобы перечитывать свой код по несколько раз, то проблемы удобства чтения кода никогда не возникнет, так как любой программист любит перерефакторивать свой код, как только это становится возможным. Только очень редко в реальных проектах достаточно времени на такие вещи. И в таком случае у программиста должен быть инстинкт написания хорошего кода без оглядки, без продумывания по десять минут названия функции.
Ну если учитывать, что Хром поддерживает экспериментальные функции веб-компонентов, то можно предположить, что и сам Гугл хорошо к такому отнесется(или уже относится). В любом случае это на данный момент скорее технология будущего, которая за год-два может стать реальностью.
В предыдущей части статьи я обещал, что вторая часть выйдет через несколько дней, но в связи с сильной загрузкой на работе у меня не было времени на переводы. Так что лучше поздно чем никогда)
Не правда, скиллы растут, я лично не перевожу материал, который и сам раньше знал, и перевожу исключительно то, что мне интересно. А в последнее время все больше короткие статьи перевожу, так как нет времени ввязываться в длинные переводы. Я тут как-бы просто привожу пример бессовестности хабры, а вы сразу на личности переходите.
Эм, ну знаете возьмитесь за переводы, это очень полезная вещь;)
С помощью этих упражнений мой маленький покер превратился в огромный блэк-джек — узнай как!Лучше скажите, где здесь ошибки, не будьте голословными.
Читайте внимательнее
Это можно делать, когда у вас куча времени. Если у программиста достаточно времени, чтобы перечитывать свой код по несколько раз, то проблемы удобства чтения кода никогда не возникнет, так как любой программист любит перерефакторивать свой код, как только это становится возможным. Только очень редко в реальных проектах достаточно времени на такие вещи. И в таком случае у программиста должен быть инстинкт написания хорошего кода без оглядки, без продумывания по десять минут названия функции.