Ну а что вы об этом слышали? Что SSD имеет ограниченное количество циклов перезаписи — это правда. Но HDD точно также не вечен. Гарантия на них дается одинаковая. И ни о каких массовых выходов из строя ssd мы до сих пор ничего не слышали. Хотя они давно на рынке.
Заявлено 10 000 циклов перезаписи как минимум. Это очень много. Просто офигенно много. Я понимаю — вы привыкли оперировать большими цифрами — и такая вроде небольшая величина вас смущает. Но вы просто посчитайте.
SSD балансирует нагрузку, записывая данные по всему диску. Значит чтобы исчерпать свой лимит вам нужно записать 10 000 * 128 Гб (примерный живой раздел с данными = размер диска/2) = 1 280 Тб. Я вот прикинул, что сам за свою жизнь закинул не более 5 Тб данных. Даже если предположить, что вы закидываете по 1 Тб в месяц (офигенно много) — то выйдет 100 лет.
Да — я брал усредненные параметры. Да — возможны экстремальные ситуации, где эта проблема проявится — ну на серверах возможно — но не на домашних компьютерах.
Та бескончность на которую я дал ссылку — универсальная :) Там можно хранить любые файлы.
Чем она не удобная — не понимаю?
Дропбокс — это облачная флешка, такого его применение — именно поэтому его использование в качестве хранилища всего так дорого — он для этого вообще не предназначен.
И да — не думаю что всем так уж нужны универсальные безлимитные хранилища (хотя они есть — я выше приводил ссылку) — организация файлов в файловой системе — тоже не верх развития инженерной мысли.
Музыку удобнее хранить в музыкальных хранилищах, фотки в альбомах, а видео — в видеоколлекциях.
Облачная бесконечность на несколько лет стоит примерно как HDD на несколько терабайт — ага.
Вот — посмотрите.
Ну а про специализированные безлимитные сервисы сервисы для хранения фотографий, видео, музыки — я вообще молчу — они все есть бесплатные.
О да!
Говорить о том стоит ли покупать SSD можно только купив SSD — вот такой парадокс. Попробовав их — вы уже никогда не захотите обратно.
Забудете про ограничение циклов перезаписи, ненадежность и прочие несерьезные страшилки про SDD. А притормаживающие HDD на системном диске для вас станут сущим кошмаром — они просто будут вас бесить — как старые смартфоны на андроиде с низкой отзывчивостью. Я уж молчу про шум и нагрев — компьютеры с HDD будут вам казаться взлетающими боингами.
Проблему небольшого размера диска решите открыв для себя мир облачных хранилищ.
Много у них слов на сайте неписано по этому поводу. Лень читать.
Может кто нибудь прокомментирует какие они дают гарантии — можно попробывать смаппить на российское законодательство.
По поводу SLA — я говорю не о гипотетический вещах, а о настоящем российском законодательстве. Вот то что я написал — это реально работает — это закон РФ — о нем все знают. Все остальное может в штатах работает — но у нас это документы совсем другого уровня.
Посмотреть рефлектором на необфусцированное скомпилированное приложение — это совершенно не то же самое что смотреть код. Там будут отличаться имена локальных переменных, отсутствоват комментарии, отличаться код внутри методов.
Будут отстутствовать интеграционные и юнит тесты, билд скрипты, документация по проекту, использованные в работе утилиты и т.д.
Вы не сможете использовать обфусцированный код напрямую в своем продакшен приложении. Вам придется его переписывать в соответсвии со стилем, принятым в рамках вашего проекта, тестировать и т.д. Алгоритм работы вы конечно можете подсмотреть — но его и придумать заново не проблема — если это обычное приложение.
Может иметь смысл только воровство всего сразу — исходников целиком. Если вы будете использовать предложенное в статье решение — это может стать реальностью.
Хотя я может вас просто не понял и вы имеете ввиду поделку на коленке а не приличного уровня проект.
Конечно же есть. Воровство кода с помощью декомпиляции всегда значительно дороже, чем сразу взять исходники, даже если это .net. Обычно по стоимости как написать заново — если это конечно не какие то хитрожопые алгоритмы.
Статья 1261. Программы для ЭВМ
Авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы), которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код, охраняются так же, как авторские права на произведения литературы.
В суде тебе будет намного труднее доказать что код твой, если у твоего конкурента в руках его точная копия.
Неее — так дело не пойдет. Собрать, задеплоить и протестировать я и сам могу — майкрософт для этого все уже сделал.
Хотелось бы сервер, на который я могу залить определенную версию проекта и использовать как тестовый контур или для демонстраций.
Но при этом оставить свои исходники при себе.
Подозреваю, что все таки была не о том насколько правильно используется JQuery.
А о том, что разработчики, которые не спускаются ниже этого фреймворка в решениях своих проблем и мыслят более высокими уровнями астракции хуже, чем те, кто лезут глубже.
Иногда, я забываю, что пишу под фреймворк, решая свои проблемы на чистом JS…
Чесно — когда внутри адекватного кода на jquery встречаешь костыли на чистом js — которые ломаются на каких нибудь версиях браузера или написаны без тестов — это кошмар.
Но я часто встречаю людей, которые знают JavaScript на уровне синтаксиса для работы только с JQuery и, при возникновении проблем, просто теряются, ругаются и ищут решения в интернете без возможности понимания и вникания в суть, требуя решения на их любимом JQuery.
Ой побольше бы таких людей — и поменьше бы «крутых спецов», которые везде суют свои кривые велосипеды.
ssd -на мой взгляд сегодня — необходимость а не роскошь. Даже в бюджетные модели ноутбуков их кажется уже ставить начали. Ультрабуки все восновном с ssd тоже. HDD. Чесно говоря совершенно отвык от этих тяжелых, греющихся, жужжащих, медленных устройств. От того, чтобы парится по поводу падений ноутбуки или того, в каком положении он лежит в сумке.
Инструментарий разработчика к тому же очень активно работает с жестким диском — разница ооочень заметна.
Вообще требования, которые я приводил к ноутбуку фактически и есть требования к устройству с топовой комплектацией топового ноутбука. И вот в этом и есть проблема.
Вы правы — я немного переборщил с определениями в угоду лучшего понимания моей мысли.
1) Коллективное владение кодом — это именно то, что я написал. Да — эта практика может эффективно существовать только если есть другие — шаринг знаний через парное программирование или как то еще.
Но значение этих двух слов в них и заключается — прочитайте их еще раз и вы поймете.
Вы можете владеть кодом, но в нем не разбираться.
2) Ревью кода — это действительно не одобрение. Это проверка кода после его написания с целью нахождения проблем. Эта проверка действительно может проходить по разному и разными людьми. Однако это именно проверка после написания кода и именно другим человеком, мозги которого не повязаны на решаемую задачу. Конечно парное программирование — это не ревью кода — это разработка кода.
Практику код — ревью следует применять для улучшения качества кода. И совершенно наплевать есть ли парное программирование или нет. Главное достаточно ли хороший получается код.
И уж конечно код ревью не имеет никакого отношения к agile.
Agile — это не собирательное название разных методик.
Это методология, основанная на правилах записанных в Agile Manifesto и специфическом наборе ценностей.
Менеджерские и девелоперские методики, которые удовлетворяют данным ценностям и правилам — мы называем Agile методиками. Да — экстремальное программирование в принципе Agile методика, но конкретно практика коллективного владения кодом не является прямым следствием правил Agile-а, а лишь косвенно с ними связана.
Коллективное владение и инспекция кода — никакие не пожелания а конкретные практики, которые применяются определенным образом.
Коллективное владение — мы декларируем, что любой разработчик имеет право без разрешения менять любую часть кода. И все — куда уж конкретнее.
Инспекция кода — мы декларируем, что никто не имеет права чекинить код, без его дополнительной проверки и одобрения другим человеком. Если у вас можно обойтись без этого — значит практика не соблюдается. Разумеется практика может распространятся не на все приложение. Если у вас используется парное программирование — значит для данного кода не используется инспекция кода. Потому что парное программирования тоже может решить те же проблемы.
Вот и все. Ничего сложного — если оперируешь конкретными понятиями. И я ничего не говорю о том, что хорошо, а что плохо — это механизмы, которые позволяют решать конкретные проблемы, в конкретных обстоятельствах.
И использовать их вот так — буздумно — как какие то мутные истины — вот это по настоящему плохо.
С первой страницы по вашей ссылке заявленным характеристикам удовлетворяют только lenovo t420 и довольно новый DELL LATITUDE E6420 в своей лучшей модификации (за 100 штук — дороговато, да?). На следующих страницах есть еще HP ProBook/EliteBook — в принципе среди них есть достойные модели, но в среднем они все тяжеленные и с отвратным качеством экрана. По факту есть еще у самсунга пара новых моделей из ноутбуков. Видел даже вроде какой то ультрабук, который удовлетворял критериям.
Вроде все.
Что то забыл?
Вы говорите о практике экстремального программирования Collective Code Ownership,
К Agile этот принцип имеет лишь очень косвенное отношение.
А практика Code Review — вообще к Agile никаким боком.
Говорить об agile стало так модно — статьи не пишет только ленивый. При всем уважении — настоятельно рекомендую ознакомится с мат частью. И начать рекомендую с Agile Manifesto.
Любые классы вообще поменять проще пареной репы, пока их никто не использует.
Во избежании неверного толкования (которое имело место), поясняю, что имею ввиду, что созданные в рамках статьи классы не используют другие слои приложения и именно поэтому их вроде бы легко рефакторить.
Например их наверняка будет использовать UI системы.
Заявлено 10 000 циклов перезаписи как минимум. Это очень много. Просто офигенно много. Я понимаю — вы привыкли оперировать большими цифрами — и такая вроде небольшая величина вас смущает. Но вы просто посчитайте.
SSD балансирует нагрузку, записывая данные по всему диску. Значит чтобы исчерпать свой лимит вам нужно записать 10 000 * 128 Гб (примерный живой раздел с данными = размер диска/2) = 1 280 Тб. Я вот прикинул, что сам за свою жизнь закинул не более 5 Тб данных. Даже если предположить, что вы закидываете по 1 Тб в месяц (офигенно много) — то выйдет 100 лет.
Да — я брал усредненные параметры. Да — возможны экстремальные ситуации, где эта проблема проявится — ну на серверах возможно — но не на домашних компьютерах.
Чем она не удобная — не понимаю?
Дропбокс — это облачная флешка, такого его применение — именно поэтому его использование в качестве хранилища всего так дорого — он для этого вообще не предназначен.
И да — не думаю что всем так уж нужны универсальные безлимитные хранилища (хотя они есть — я выше приводил ссылку) — организация файлов в файловой системе — тоже не верх развития инженерной мысли.
Музыку удобнее хранить в музыкальных хранилищах, фотки в альбомах, а видео — в видеоколлекциях.
Вот — посмотрите.
Ну а про специализированные безлимитные сервисы сервисы для хранения фотографий, видео, музыки — я вообще молчу — они все есть бесплатные.
Говорить о том стоит ли покупать SSD можно только купив SSD — вот такой парадокс. Попробовав их — вы уже никогда не захотите обратно.
Забудете про ограничение циклов перезаписи, ненадежность и прочие несерьезные страшилки про SDD. А притормаживающие HDD на системном диске для вас станут сущим кошмаром — они просто будут вас бесить — как старые смартфоны на андроиде с низкой отзывчивостью. Я уж молчу про шум и нагрев — компьютеры с HDD будут вам казаться взлетающими боингами.
Проблему небольшого размера диска решите открыв для себя мир облачных хранилищ.
Так что я очень понимаю Торвальдса.
Может кто нибудь прокомментирует какие они дают гарантии — можно попробывать смаппить на российское законодательство.
Посмотреть рефлектором на необфусцированное скомпилированное приложение — это совершенно не то же самое что смотреть код. Там будут отличаться имена локальных переменных, отсутствоват комментарии, отличаться код внутри методов.
Будут отстутствовать интеграционные и юнит тесты, билд скрипты, документация по проекту, использованные в работе утилиты и т.д.
Вы не сможете использовать обфусцированный код напрямую в своем продакшен приложении. Вам придется его переписывать в соответсвии со стилем, принятым в рамках вашего проекта, тестировать и т.д. Алгоритм работы вы конечно можете подсмотреть — но его и придумать заново не проблема — если это обычное приложение.
Может иметь смысл только воровство всего сразу — исходников целиком. Если вы будете использовать предложенное в статье решение — это может стать реальностью.
Хотя я может вас просто не понял и вы имеете ввиду поделку на коленке а не приличного уровня проект.
Статья 1261. Программы для ЭВМ
Авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы), которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код, охраняются так же, как авторские права на произведения литературы.
В суде тебе будет намного труднее доказать что код твой, если у твоего конкурента в руках его точная копия.
Хотелось бы сервер, на который я могу залить определенную версию проекта и использовать как тестовый контур или для демонстраций.
Но при этом оставить свои исходники при себе.
А о том, что разработчики, которые не спускаются ниже этого фреймворка в решениях своих проблем и мыслят более высокими уровнями астракции хуже, чем те, кто лезут глубже.
Иногда, я забываю, что пишу под фреймворк, решая свои проблемы на чистом JS…
Чесно — когда внутри адекватного кода на jquery встречаешь костыли на чистом js — которые ломаются на каких нибудь версиях браузера или написаны без тестов — это кошмар.
Ой побольше бы таких людей — и поменьше бы «крутых спецов», которые везде суют свои кривые велосипеды.
Инструментарий разработчика к тому же очень активно работает с жестким диском — разница ооочень заметна.
Вообще требования, которые я приводил к ноутбуку фактически и есть требования к устройству с топовой комплектацией топового ноутбука. И вот в этом и есть проблема.
1) Коллективное владение кодом — это именно то, что я написал. Да — эта практика может эффективно существовать только если есть другие — шаринг знаний через парное программирование или как то еще.
Но значение этих двух слов в них и заключается — прочитайте их еще раз и вы поймете.
Вы можете владеть кодом, но в нем не разбираться.
2) Ревью кода — это действительно не одобрение. Это проверка кода после его написания с целью нахождения проблем. Эта проверка действительно может проходить по разному и разными людьми. Однако это именно проверка после написания кода и именно другим человеком, мозги которого не повязаны на решаемую задачу. Конечно парное программирование — это не ревью кода — это разработка кода.
Практику код — ревью следует применять для улучшения качества кода. И совершенно наплевать есть ли парное программирование или нет. Главное достаточно ли хороший получается код.
И уж конечно код ревью не имеет никакого отношения к agile.
Это методология, основанная на правилах записанных в Agile Manifesto и специфическом наборе ценностей.
Менеджерские и девелоперские методики, которые удовлетворяют данным ценностям и правилам — мы называем Agile методиками. Да — экстремальное программирование в принципе Agile методика, но конкретно практика коллективного владения кодом не является прямым следствием правил Agile-а, а лишь косвенно с ними связана.
Коллективное владение и инспекция кода — никакие не пожелания а конкретные практики, которые применяются определенным образом.
Коллективное владение — мы декларируем, что любой разработчик имеет право без разрешения менять любую часть кода. И все — куда уж конкретнее.
Инспекция кода — мы декларируем, что никто не имеет права чекинить код, без его дополнительной проверки и одобрения другим человеком. Если у вас можно обойтись без этого — значит практика не соблюдается. Разумеется практика может распространятся не на все приложение. Если у вас используется парное программирование — значит для данного кода не используется инспекция кода. Потому что парное программирования тоже может решить те же проблемы.
Вот и все. Ничего сложного — если оперируешь конкретными понятиями. И я ничего не говорю о том, что хорошо, а что плохо — это механизмы, которые позволяют решать конкретные проблемы, в конкретных обстоятельствах.
И использовать их вот так — буздумно — как какие то мутные истины — вот это по настоящему плохо.
С первой страницы по вашей ссылке заявленным характеристикам удовлетворяют только lenovo t420 и довольно новый DELL LATITUDE E6420 в своей лучшей модификации (за 100 штук — дороговато, да?). На следующих страницах есть еще HP ProBook/EliteBook — в принципе среди них есть достойные модели, но в среднем они все тяжеленные и с отвратным качеством экрана. По факту есть еще у самсунга пара новых моделей из ноутбуков. Видел даже вроде какой то ультрабук, который удовлетворял критериям.
Вроде все.
Что то забыл?
К Agile этот принцип имеет лишь очень косвенное отношение.
А практика Code Review — вообще к Agile никаким боком.
Говорить об agile стало так модно — статьи не пишет только ленивый. При всем уважении — настоятельно рекомендую ознакомится с мат частью. И начать рекомендую с Agile Manifesto.
Во избежании неверного толкования (которое имело место), поясняю, что имею ввиду, что созданные в рамках статьи классы не используют другие слои приложения и именно поэтому их вроде бы легко рефакторить.
Например их наверняка будет использовать UI системы.