Ответы пользователя по тегу JavaScript
  • Не говнокод ли я пишу?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Есть jquery. Сто лет ему. Немного (сильно) сокращает код.
    this.onMouseMoveBinded = this.onMouseMove.bind(this);
    this.onMouseEndBinded = this.onMouseEnd.bind(this);


    Не прочитать.
    if( typeof (this.obj) === 'undefined' ) this.obj = opt.el;

    Лучше так.
    if(this.obj === undefined) {
    	this.obj = opt.el;
    }

    Вам срочно нужна векторная алгебра.
    // ***
    	this.shiftX = e.clientX - thumbCoords.left;
    	this.shiftY = e.clientY - thumbCoords.top;
    //***
    	this.coords = {
    		top: e.clientY - this.shiftY - this.parentShift.top,
    		left: e.clientX - this.shiftX - this.parentShift.left
    	};
    //***
    	this.coords.top = e.clientY - this.shiftY - this.parentShift.top;
    	this.coords.left = e.clientX - this.shiftX - this.parentShift.left;
    //***
    	this.rx = this.px - this.kx;
    	this.ry = this.py - this.ky;
    //***

    Ну jquery же.
    doc.documentElement.classList.remove('grabbing');
    doc.removeEventListener('mousemove', this.onMouseMoveBinded);
    doc.removeEventListener('mouseup', this.onMouseEndBinded);

    Вообще, подумайте над названиями. Может оно и адекватно, но мне - непонятно. Откуда тут напряжение взялось?
    function Tension(opt){
    	dragNdrop.apply(this, arguments);
    }

    Не помню как сейчас, но, ЕМНИП, в js объекты-классы определяются через var.
    Tension.prototype = Object.create(dragNdrop.prototype);
    Tension.prototype.constructor = Tension;

    То есть декларирование Tension должно быть каким-то таким:
    var Tension = function (opt){
    	dragNdrop.apply(this, arguments);
    }

    Снова не прочитать условия. Не жалейте строк! Алсо, всё в одну кучу - UI, логику, физику - это плохой знак.
    function Slider(opt){
    	if(typeof (this.obj) === 'undefined') this.obj = opt.thump;
    	if(typeof (this.slider) === 'undefined') this.slider = opt.slider;
    	dragNdrop.apply(this, arguments);
    }


    new dragNdrop({
    	el: doc.getElementById('ball1'),
    	physiq: true
    });
    
    new dragNdrop({
    	el: doc.getElementById('ball2')
    });
    
    new Tension({
    	el: doc.getElementById('square1')
    });
    
    new Slider({
    	slider: doc.getElementById('slider'),
    	thump:  doc.querySelector('.thumb'),
    	physiq: true
    });
    
    new StepSlider({
    	el: doc.getElementById('slider-step'),
    	from: 5,
    	to: 40
    });

    Плачу кровавыми слезами. Что это? Не боитесь сборщика мусора? Не надо так. Вообще global space - не есть хорошо.

    Итого мы имеем сложно читаемую математику, паршивый нейминг, неудобные условия и нежелание следовать каким-то best-practice. Это всё не фатально, более того - прототип рабочий. Меняться вам или нет - решайте сами. Из важного, я бы посоветовал сделать всё читаемым, а для этого потребуется адекватный нейминг, не сваливать всё в кучу и следовать неформальным правилам. В остальном, javascript не идеальный вариант, чтобы показывать задротство в области clear code. И с паттернами у него беда.
    Ответ написан
    4 комментария
  • Как занести текст из js в переменную php?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Эм? А ничего, что js это клиентская машина, а php - ваша? Другими словами, они могут Атлантическим океаном быть разделены. Можно, конечно, голубей отправлять, но проще воспользоваться websockets или GET/POST запросом (ajax).
    Ответ написан
    6 комментариев
  • Стоит ли отказываться от JS в мобильных версиях сайта?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    В принципе, верно все написали, что экономить трафик вырезанием JS - не лучшая история. Однако, лично меня жутко бесят сайты, что нагромоздили JS донельзя и что не ткнёшь пальцем - подвисает на пол секунды. Сам по себе браузер вещь довольно громоздкая и жрёт ресурсы неимоверно, а JS рад украсть ещё пару... миллионов тактов. Тогда как по производительности нынешние мобильные камни едва догоняют Pentium D, а это, простите, лет десять назад когда рендер JS-ом ещё только появлялся, а красивые странички напичканные (или полностью из) флешем (который имел GPU-ускорение) были пиком моды.
    Так что по правде - важно соблюдать компромисс. Да где угодно его важно соблюдать - пока грузится голый html, а потом рендерится JS-ом ещё несколько секунд (ибо не сразу всё подгружается) и начинает сиять всеми цветами радуги - чувствуется вся убогость www. Просто помните, что Вы пишите под браузер, который далеко не такой умный и быстрый, как хвалят его в Google, Apple, MS или Mozilla, а наоборот - неповоротливый, жадный до ресурсов и очень зависимый от качества Интернет-соединения.
    Так что вот правильный воркфлоу:
    1. Рендер на сервере в html.
    2. Упаковка JS и CSS скриптов в один .js и .css файл соответственно.
    3. Сжатие GZIPом упакованных .js и .css файлов и рендеренный .html файл.
    4. Передача сжатых данных на клиентское приложение (браузер).

    А вот небольшие наблюдения по поводу JS:
    Ответ написан
    4 комментария
  • Как быстро вставить html с скриптами с помощью jquery?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Товарищ, если вам требуется загрузить страницу со скриптами, которых нет на вашей странице - что-то не так с архитектурой. Совсем не так. Но если засела асинхронная ересь в голове - грузите страницу, выпарсивайте скрипты и грузите отдельно.
    Ответ написан
    Комментировать
  • Как закодировать цифры в символы?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Окай. Делается это очень просто - мощность алфавита равняется 12ти, то есть нам потребуется 4 бита, чтобы его закодировать (хотим меньше - придётся обратится к хафманам). То есть свичём или ифами выбираем нужный квартет битов. Другими словами имеем отображение из символа в полубайт. Чтобы получать нормальные байты нужно разбивать на пары и складывать побитово результаты каждого символа с соответствующим смещением.

    Есть способ попроще, возможно даже быстрее в скорости работы. Берём все пары [0-9\,\-]{2} и строим по ним хэш-таблицу, или те же самые ифы-свичи. Таким образом мы отказались от мутных складываний, а если использовали хэш-таблицу это ещё и быстрее будет. То есть в результате у нас будет отображение пар небольшого алфавита в байт.

    Что-то мы естественно потеряем - мощность алфавита не кратна двойке - так что если требуется минимизировать трафик, возможно стоит сразу поточно жать в gzip, без предварительных манипуляций.
    Ответ написан
    Комментировать
  • Стоит ли изучать JavaScipt и C# одновременно с нуля?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Ну, тут зависит от человека... В общем случае, ответ, конечно нет. Причём это про любое так можно сказать. Не важно, насколько они похоже, при изучении чего либо требуется тотальная концетрация.

    Однако. Стоит заметить, что во-первых, JS и C# таки похожи в синтаксисе. По крайне менее, точно будут случаи, когда программу на C# почти без изменений браузер сожрёт да не подавиться.

    Но тут вот что важно помнить. C# - это такой канонический ООП. C# стабилен, C# стандартен, C# быстр. И да, он таки удобен. В чём-то. В большинстве.

    JS - это попытка впихнуть ООП в хаскел, дополнительно заменив все ключевые слова на куда большие в размерах. Однако, во-первых, зачем-то имплементировали прототипную модель наследования. Она удобна в относительно редких случаях. Во-вторых, JS сложен, а от этого сложна и компиляция и исполнение, да даже для освоения он сложен. В-третьих, JS-ов много. Вообще, JavaScript - это имплементация спецификаций ECMAScript. Как и ActionScript. И ещё тысяча этих script'ов. Однако. Есть ещё и DOM. И с ней надо работать. А это тоже медленная штука. И вообще - браузер очень медленная штука. Отчасти это связано с тем, что стандарт действительно сложен, отчасти с тем, что современные страницы мало чем отличаются от сложных программных продуктов, однако часто выполнены с ошибками (бывают даже умышленные ошибки). Причём доступа к железу нет почти никакого. Отсюда - сложный контроль производительности. Отсюда...

    А... Что там. JS убог. Чуть менее чем полностью. Если нет нужны верстать HTML не трогайте его вовсе. Если есть нужда - то придётся. В любом случае. Даже не смотрите на CoffeScript, TypeScript и подобные. Их можно будет изучить. Потом.

    Забыл написать самое главное. Программирование - штука многогранная. И как я писал выше - JS убог. Но так уж случилось - просили одно, хотели другое, выходило третье, а вышло - четвёртое. И всё перемешалось, умешалось, замешалось и.. Получился такой вот страшный гибрид. Функциональный, да не очень. Объектный, да не совсем. Портативный, да тоже как-то не сложилось целиком. Однако, он всё таки очень многогранный. Несомненно, те практики, которые Вы получите при изучении JS могут очень сильно помочь при использовании C#. И наоборот. Классические подходы разные, однако классика не всегда подходит.
    Ответ написан
    2 комментария
  • Стоит ли использовать RSA?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    И да и нет одновременно.

    (обновлено, ибо внезапно прочитал и половину не понял - видимо писал на "потоке")
    RSA стоит использовать лишь для шифрования других ключей - ключей симметричных алгоритмов шифрования. AES, ГОСТ 28147-89, 3DES и другие. Почему? Во-первых, симметричные алгоритмы более устойчивы к взлому при большом известном закрытом тексте, тогда как ассиметричное шифрование потенциально имеет изъяны. В том смысле, что (почти) любое ассиметричное шифрование использует задачу NP-класса (точнее - NP-полную задачу): факторизация числа (RSA), декодирование полных (общих) линейных кодов (McEliece), вычисление дискретного логарифма на элептической кривой (ГОСТ Р 34.10-2012), или в конечном поле (Elgamal). Другое дело, что любая эта задача потенциально - решаемая. В случае с симметричным шифрованием действительно стоит лишь надеяться на чудо (в ГОСТе разрешено выбирать любые s-блоки, так что криптоаналитику ничего не остаётся, как молиться пролетариату в надежде на терморектальный криптоанализ). В случае же с ассиметричным шифром в дело вступают две вещи - высокая сложность реализации действительно стойкого алгоритма (ассиметричные шифры очень сложны и полны нюансов, не учитывая которые можно запросто порушить систему), низкая скорость работы (в силу того, что приходиться использовать очень абстрактные математические функции, сложно реализуемые аппаратно и таящие в себе множество низкоуровневых операций) при требовании к очень длинным ключам заставляют использовать небольшие ключи для того, чтобы не ждать вечность.

    Однако. Здесь имеется странный парадокс. Если данные очень важные и на их защиту можно убить несколько миллионов енотов, то надо использовать только ассиметричный шифр. Потому что, он потенциально даёт большую стойкость. Парадокс здесь в том, что если классы P и NP неравны, то мы получаем едва ли не идеальную и приемлемую по стоимости защиту, так как есть возможность сложной организационной защиты.
    (здесь было многое отправлено в топку)

    Окай, посмотрим на стандартную схему с Алисой, Бобом и Евой:
    Алиса -> c = E(m, Eb) -> -------- -> D(c, Db) -> Боб (
                                     |
                                     |
                                     v
                         Ева <- c, E, D, d

    здесь m - текст, который надо передать (сообщение)
    c - шифротекст
    E - функция шифрования (получения из сообщения шифротекста)
    D - функция дешифрования, иначе - обратная функция шифрования (получения из шифротекста - сообщения)
    Eb, Db - секретный и открытый ключи Боба (в литературе используется различное обозначение, здесь так)
    Собственно, Ева знает всё о функциях шифрования и дешифрования, имеет доступ к шифротексту и будем считать, что она получает и открытый ключ.

    Теперь, что нам это даёт? А это нам даёт возможность наплодить большое количество ключей и шифровать каждое сообщение отдельным ключём. Потенциально, но если есть $$$, то можно скупить половину серверов страны, если не планеты и радоваться жизни. Хотя ровно так же можно поступить и с симметричным шифрованием, и называется это одноразовым блокнотом, используют и различные режимы шифрования и всё равно выходит профитнее. Где же профит здесь?
    Во-первых, если нужно передавать по каналу, а не хранить, то можно генерировать ключи налету и после расшифровки их уничтожать. По сути, получиться что для того, чтобы получить сообщение длины l бобу потребуется передать и ключей в общей сумме длины l. Много? Да. Профитно? Очень - ибо мы реализуем
    ассиметричный одноразовый блокнот (упс), который, однако, нет никакого смысла использовать нет - слишком дорого. Да и не всегда возможно - порой обратный канал чрезвычайно узкий.
    Во-вторых, есть способ организовать защиту, основанную на иерархии пользователей. То есть майор Алиса написала отчёт, который ей надо отправить подполковнику Бобу. При этом читать этот отчёт должны иметь право все, кто равен или выше подполковника.
    В-третьих, как писалось выше, сложность взлома достаточно велика. И не только потому, что P != NP. Даже P довольно большое получается, поэтому и используют асимметричный шифр для передачи ключей симметричных ключей. Но и взлом получается очень не простым из-за тяжёлых математических абстракций. Обычно. Да, RSA можно "взломать" перебрав все возможные делители, но это долго из-за астрономического размера ключа. А способы обхода или упрощения опираются на такой зубодробительный матан, что попытка как-то это реализовать заставит использовать сами по себе очень тяжёлые операции. Так это при работе с банальными числами (и это показывает, насколько плохо развита теория чисел), а что если уйти на эллиптическую кривую - аналитическая геометрия развита может чуть лучше, но абстракции намного тяжелее для компьютеров. И даже использование графических карт не помогает, ведь есть ещё и макэлис. Я к тому, что O(2^32) для симметричного шифра и O(2^32) для асимметричного шифра не очень таки равны. Так же не равны, как не равны день и месяц.

    Но самое главное. Сегодня всё что угодно можно взломать. А то, что нельзя взломать - бесполезно (ибо либо уничтожено полностью, либо предоставляет такие же непосильные сложности для расшифровки и получателю). Во-первых, атака может быть не на сами шифры, а на организационные методы (которые, можно улучшить применением асимметричного шифра). Во-вторых, некоторые шифры таки имеют изъяны, просто возможно о них знают ограниченный круг лиц; привет масонам. И, наконец, криптоаналитик может быть просто ну очень удачлив.

    Поэтому шифрование надо использовать соразмерно цене риска. Чем выше риск - тем сильнее шифрование, но самое главное - сложнее и дисциплинированнее организационные меры. Согласитесь - бесполезно иметь централизованное хранилище сертификатов с одним сервером в бункере за 200 км под землей и круглосуточной охраной из армии маленькой страны, всего лишь одним портом торчащим во внешний мир с каналом около 200 бит в секунду и постоянным наблюдением за организационными методами (авторизация, доступ и подобной)... Имея пароль на суперюзер - qwerty, и держа на винчестере архив с котиками.
    Ответ написан
    Комментировать
  • Как посмотреть http запросы, которое посылает приложение (mac)?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    В wireshark фильтруйте по 80 порту (по destination) и... Смотрите =)
    Ответ написан
    2 комментария
  • Объясните что такое полиморфизм простыми словами ?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

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

    Собственно, представим себе рядом стакан, кружку, чайник, кофемашину, велосипед и скейт. Что между ними всеми общего? Ну как минимум то, что они есть. То есть это - объекты, которые были созданы. Но как они были созданы? Скорее всего на заводе производителя по чертежам. Ок, чертежём назовём конструктор. Ну а класс? А что это такое? А его нет в нашей вселенной - эта сущность есть абстракция, что живёт лишь в наших мыслях. В реальном мире её нет и никогда не будет, такова уж физика - ей по барабану, что птицы и млекопитающие имеют дальних родственников - она лишь обеспечивает возможность естесственного отбора. А уж родственников друг другу находим мы, люди.

    С объектами и классами разобрались, а что же там с нашими стаканами и велосипедами. Мы уже поняли, что всё это объект, то есть грубо можно все объекты наследовать от какого-нибудь суперпредка, суперкласса, что и реализовано в некоторых языках. Но что другого общего между скейтом и стаканом, например? Конечно, можно углубляться и считать, что они все из молекул, и они все из твёрдых веществ. Однако это всё бред и СПГС, так что ответ прост - да ничего. То есть это совершенно разные объекты с совершенно разным функционалом. Более того - естесственно компьютерные модели и иерархии будут сильно отличатся от физик и химий. И это нормально, вопрос об адекватностях моделей ставиться лишь когда модель неадекватна, а до тех пор пилить можно что угодно, лишь бы работало.

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

    Однако что с остальным? У нас ещё абстракция, инкапсуляция и наследование. Ок, начнём с наследования, так оно наиболее близко. Вот что у нас общего между стаканом и кружкой? Ну в оба можно налить воду, но у кружки есть ручка чтобы держаться. То есть можно придумать некий общий класс - ёмкость. Однако что это за класс? Можно например за этот класс взять стакан, тогда все ёмкости по дефолту стаканы, а всё остальное - видоизменённые стаканы. Но кому-то больше нравяться кувшины, например некоторые чики насят их на голове, считая что это удобно. Ну и пусть носят, но как-то же решить надо, что главнее и идеальнее. Так вот - недостяжимый идеал и есть главный - это называется абстрактный класс. То есть ёмкость, что невозможно создать, для которого нет полного чертежа. А все чертежи, что дополнили до полного - есть наследованные классы от класса ёмкость.

    Тут мы подошли к абстракции. Вот такое иерархическое наследование приводит нас к, возможно главной, идее ООП. Вот мы взяли и выделили всё, куда можно налить воду в отдельный класс, нарисовали общий чертёж, но специально не доделали его, оставив зазор для будущих творцов, и назвали чертёж - ёмкость. Тысячи лет изобретатили всех миров создают свои ёмкости, одна лучше другой. Для разных людей - по разному, конечно. Но каждый раз группировать молекулы стекла определённым образом - непростая задача. Поэтому ремесленники пошли на хитрость, они создали тайный совет ремесленников мира и решили делиться друг с другом своими наработками. То есть создавать мелкие чертежи и объявлять классом, например, извлистой ручки в форме ленты Мёбиуса, например. Возможно такая ручка удобно только инопланетным существам, но чертёж создан и к нему можно ссылаться при создании своего чертежа. Таким образом мы абстрагируемся от низкоуровневой задачи "формирования ёмкостей посредством перемещения молекул" к "конструированию ёмкости посредством совмещения деталей, элементов". Это и есть абстракция.

    Но мы подошли к последнему пункту - инкапсуляция. Она неразрывна с абстракцией, и по сути благодаря ей она и работает. Инкапсуляция - это своеборазный клей (или синяя изолента), которым склеивают разные чертежи в один. То есть совмещение деталей для создания своей - это и есть инкапсуляция. Причём при совмещении мы можем не описывать детали этого совмещения (то есть члены класса могут быть приватными), таким образом помогая абстрагироваться тем, кто этот чертёж использует. Вот посмотрим на чайник - что это такое? Это стакан (или кружка) к которому снизу (а может внутри по середине?) приклеен нагревательный элемент. Пустив по нему ток, согласно инкапсулированному в нагревательный элемент закону Ома, будет выделяться тепло и нагреваться вода. А кофемашина? Это куда более сложное устройство, с множеством насосов, ёмкостей, шлюзов, измельчителей и чайников. И всё склееное клеем. А может синей изолентой. Это снова инкапсуляция.

    Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.
    Ответ написан
    3 комментария
  • Как сменить картинку на JavaScript?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    <label id="sun"></label>
    
    <script>
    var sun = Math.floor(1000 * Math.random());
    document.getElementById('sun').innerHTML=("<img src=" + sun + ".png />");
    </script>


    Ваш К.О.
    Ответ написан
    Комментировать
  • Можно ли загрузить страницу через js?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    8 комментариев
  • Как написать условие?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Если хочется своего велосипеда вместо использования Array.every (спасибо @k12th ), то как-то так:
    var num = 5,
        all = true,
        arr = [1, 5, 7, 9];
    
    for(var i = 0; i < a.length && all; i++) {
        if( all )
            all = arr[i] == num;
    }

    Можно даже более по-извращенски:
    for(var i = 0; i < a.length && (all = arr[i] == num); i++);
    Ответ написан
    Комментировать
  • Есть ли библиотеки облегчающие построение графиков на SVG?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Попробуйте рафаэля.
    Ответ написан
    Комментировать
  • Зависает браузер при выводе большого объема записей с БД (items.length >= 5000)?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Как вариант, можно по /ajax/items.php возвращать не все 5000 элементов, а кусками. Например, по /ajax/items.php?count возвращать количество страниц, а по /ajax/items.php?number возращать страницу из 500 элементов. И при добавлении на страницу использовать небольшую задержку в миллисекунду.

    Правда, вопрос: почему нельзя сделать PHP-скрипт, который возвращал сразу готовую страницу со всем контентом. Зачем ajax?
    Ответ написан
    3 комментария
  • Какой лучший веб-редактор под Linux?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Странно, что никто не вспомнил про Atom. Правда он в разработке, но вроде можно и собрать - многообещающий проект.

    А вообще, есть, наверное, три пути.

    Костыльный: запустить под wine'ом, или поставить виртуалку. На самом деле, ставить виртуалку весьма оправданно, так как в этом случае получаете чистую систему, которую потом можно будет быстро развернуть где угодно и не получить ничего лишнего. Правда всё равно - ставить *nix, а на него винду ради Dreamweaver не айс.

    Нормальный: sublime text. Под него есть множество best и good practice, он действительно очень настраиваемый и в тоже время довольно удобный.

    Unix-way: vim. Из коробки очень не красивый, но пара настроек - и уже светиться всеми огнями. Юзабельность высокая даже без настроек. Из плюсов - работает и под ssh не плохо. Из минусов - долгая акклиматизация. Но потом будет сложно вернуться куда-либо.

    Алсо, часто слышу про webstorm - мощная штука. Да и с руби у jetbrains всё хорошо. Правда продукты платные, а лишних средств ради попробовать нет (пары недель на один проект вряд ли хватит, так что я даже не пробовал).

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

    UPD.
    Дистрибутив - сам пользуюсь ArchLinux. Но это довольно сложный вариант, хотя от документации наступает лёгкое чувство эйфории. Не хочу никуда переходить теперь, ибо Ubuntu для меня теперь - мощный и сложный китайский комбайн без нормальной документации, который непонятно как работает. Так что предпочитаю плугу - пусть и руками много работать, зато починить легко. Да и документация к этой плуге на уровне.
    Ещё немного пробовал на debian пересесть, когда появлялись проблемы со слишком новыми драйверами. В общем, впечатления хорошие. Но всё равно остаётся привкус недосказанности. Да и его стабильность преувеличена - нужный мне драйвер оказался слишком старым =) И плюшек нужных не получил. Так что откатился на opensource драйвер и попрощался с игрушками. Ещё пробовал Mint. На самом деле, очень симпатичный дистр. Шустрый, красивый и удобный настолько, насколько может быть Linux таким. То есть действительно очень быстрый, но немного не красивый и порой появляется некоторое чувство неудобства (впрочем, по сравнению с windows, с которым у меня это чувство почти постоянно, всё не так плохо).
    В общем, по уменьшению степени задротства (но увеличении кол-ва магии):
    ArchLinux, Debian, Mint, Ubuntu.
    Ответ написан
    2 комментария