Программирование, т. 7

​

​

 

ох ебать красота

https://habrahabr.ru/company/aladdinrd/blog/329166/

 

на непатченной винде драйвер нтфс зависнет от картинки в браузере)

 

хром по какой-то случайности не зависает, а фф и ие вешают ос

Тоесть я сюда(в эту тему) вкидывал уже 2 бага работающих на всех виндах от XP до 10, первый был баг в НТФС рабочий с примером, и второй способо выжрать всю оперативку 2 строчками на джаваскрипте

​

​и ты восхищаешся какойто очередной статьей на хабре уровня хело ворда?

​

​если я запощу свои два поста на хабре ты также пойдеш восищаться ими?

​мда

Просто ты какой-то ебанутый, на тебя внимания никто не хочет обращать

Вот такая хуйня нон-стоп в каждом резюме 

PHP уровень1 бляяя, я прошел три их курса и написал свой говно проектик, на собесе прошел их тесты по пхп + js, потом достал свой ноут и показал это проектик, который мне кажется и стал причиной того, что взяли на работу

^ ну ты с проектиком врывался, а я наблюдаю только как жалкие менеджеры или неудавшиеся предприниматели решили заработать больше денег, что решили делать в программировании, не имея знаний/желания особого изучать всё это

нет чтобы стать тестировщиками 

тупицы ебаные 

нужен совет,
Cоздаю просту галерею на чистом js 

КАК лучше загружать картинки?  указывать url как src  для <image> или используя XMLHttpRequest (в этом случае нужно декодировать в base64) через url"(data:image/..") да и большенство картинок не доступно 
 

хрень в том что задаю один и тот же url"(data:image/..")  для миниатюры и для большой картинки, хз как это скажется если будет дохуя картинок

Галерея в плане дохуялион картинок, ты скроллишь вниз, и он с помощью lazyload появляются?

Если да и lazyload обязателен (да еще и подгрузка при скроллинге), то можно так. Если ты пишешь на каком-нибудь jQuery, то рендеришь простые <div/>'ы, у которых аттрибутом указан урл картинки (data-img="hui.jpg")

Затем ебашишь функцию, которая триггерится по скроллу и проходит по дивам, которые еще не загрузили картинки, и чекает находятся ли они во вьюпорте (в видимости экрана). Сам нагуглишь как такое делать, заодно поебешься с оптимизациями, полезный опыт. В общем див во вьюпорте - создаешь внутри <img /> и назначаешь ему src на основе data-img дива (самый примитивный вариант). И твоя картинка загружается.

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

+ сверху еще прикручиваешь подгрузку данных новой пачки картинок, ибо если картинок миллион, то грузить данные для всего миллиона на старте это хуйня. Грузишь по 100+ например, учитывая что это будут всего-лишь урлы и размеры пикчи. + грузить скорее всего ты должен уменьшенные версии картинок, а по клику показывать фулл версию (в стиле лайтбокса), которая может быть гигантской и весит 5+ мегабайт.

Или ты вообще говорил о каком-нибудь слайдере/карусели?

По XSLT трансформации подъехала задачка

2017 

Галерея в плане дохуялион картинок, ты скроллишь вниз, и он с помощью lazyload появляются?

Если да и lazyload обязателен (да еще и подгрузка при скроллинге), то можно так. Если ты пишешь на каком-нибудь jQuery, то рендеришь простые <div/>'ы, у которых аттрибутом указан урл картинки (data-img="hui.jpg")

Затем ебашишь функцию, которая триггерится по скроллу и проходит по дивам, которые еще не загрузили картинки, и чекает находятся ли они во вьюпорте (в видимости экрана). Сам нагуглишь как такое делать, заодно поебешься с оптимизациями, полезный опыт. В общем див во вьюпорте - создаешь внутри <img /> и назначаешь ему src на основе data-img дива (самый примитивный вариант). И твоя картинка загружается.

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

+ сверху еще прикручиваешь подгрузку данных новой пачки картинок, ибо если картинок миллион, то грузить данные для всего миллиона на старте это хуйня. Грузишь по 100+ например, учитывая что это будут всего-лишь урлы и размеры пикчи. + грузить скорее всего ты должен уменьшенные версии картинок, а по клику показывать фулл версию (в стиле лайтбокса), которая может быть гигантской и весит 5+ мегабайт.

 

Или ты вообще говорил о каком-нибудь слайдере/карусели?

это учебное задание(использовать фреймворки и jQiery запретили ). до полноценной галереи далеко ему.

сетки не нужно, по макету это слайдер с миниатюрами ,

это учебное задание(использовать фреймворки и jQiery запретили ). до полноценной галереи далеко ему.

сетки не нужно, по макету это слайдер с миниатюрами , после просмотра всех картинок (url которых хранятся в json файле) будут автоматом подгружатьcя другие картинки  по xmlHttpRequest c flickr.com.

ом-нибудь слайдере/карусели?

 

Слайдер с миниатюрами и при этом еще и динамической подгрузкой? Что за наркомания? Ибо для слайдера надо знать заранее количество элементов, чтобы миниатюры расставить (+место ограниченное по горизонтали)

По поводу фликера - на 100% там юзается api, которое возвращает json с урлами картинок, а не их блобы, так что никакие ссаные base64 юзать не надо.

По поводу изначального json - ну это все просто, парсишь json, вставляешь картинки на основе массива и все, изимод.

когда слышу "галерея, слайдер, карусель, аккордеон(?)", то по дефолту представляю карусельку, хоть и зн че куда можно подразуметь

один раз бабе пытался объяснить что такое карусель на примере сайта owl-carousel.com, и она не вкурила, я до сих пор не могу это принять

По XSLT трансформации подъехала задачка

2017 

а что, хмл умер, что не нужны хслт?

кстати XSLT внезапно норм

тот же реакт

 

Галерея в плане дохуялион картинок, ты скроллишь вниз, и он с помощью lazyload появляются?

Если да и lazyload обязателен (да еще и подгрузка при скроллинге), то можно так. Если ты пишешь на каком-нибудь jQuery, то рендеришь простые <div/>'ы, у которых аттрибутом указан урл картинки (data-img="hui.jpg")

Затем ебашишь функцию, которая триггерится по скроллу и проходит по дивам, которые еще не загрузили картинки, и чекает находятся ли они во вьюпорте (в видимости экрана). Сам нагуглишь как такое делать, заодно поебешься с оптимизациями, полезный опыт. В общем див во вьюпорте - создаешь внутри <img /> и назначаешь ему src на основе data-img дива (самый примитивный вариант). И твоя картинка загружается.

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

+ сверху еще прикручиваешь подгрузку данных новой пачки картинок, ибо если картинок миллион, то грузить данные для всего миллиона на старте это хуйня. Грузишь по 100+ например, учитывая что это будут всего-лишь урлы и размеры пикчи. + грузить скорее всего ты должен уменьшенные версии картинок, а по клику показывать фулл версию (в стиле лайтбокса), которая может быть гигантской и весит 5+ мегабайт.

 

Или ты вообще говорил о каком-нибудь слайдере/карусели?

это учебное задание(использовать фреймворки и jQiery запретили ). до полноценной галереи далеко ему.

сетки не нужно, по макету это слайдер с миниатюрами , после просмотра всех картинок (url которых хранятся в json файле) будут автоматом подгружатьcя другие картинки  по xmlHttpRequest c flickr.com.

 

Жаль что вас в учебном заведении не учат формулировать задачу нормально.

Если нужно работать с картинкой как с блобом, то лучше всего создавать инстанс Image ((new Image).src = url), если надо по xhr тащить, то на здоровье, никто не мешает указать тебе, что ты тянешь блоб в xhr (xhr.responseType = "arraybuffer"; or "blob"), потом уже переделываешь буффер в блоб, или если у тебя сразу блоб, то переделываешь его в картинку, создавая URL объект, через  URL.createObjectURL(blob) а потом поставляешь результат в виде src для инстанса Image.

Тут ты можешь обломиться на правах. Не уверен как это работает сейчас, но раньше я сталкивался с проблемами, что без нужных хедеров (cross-origin которые) мне блоб парсить не давало. Что логично.

То есть, если угарать по хуйне, и делать дела ради дел, то код выглядел бы примерно так.

var xhr = new XMLHttpRequest();

xhr.open("GET", "http://prodota.ru/forum/uploads/profile/photo-6583.png?_r=1467265626", true);

xhr.responseType = "arraybuffer";

xhr.onload = function(e) {
    var arrayBufferView = new Uint8Array(this.response);
    var blob = new Blob([arrayBufferView], {type: "image/jpeg"});

    var urlCreator = window.URL || window.webkitURL;
    var imageUrl = urlCreator.createObjectURL(blob);

    var img = new Image();
    img.src = imageUrl;

    document.body.appendChild(img)
};

xhr.send();

Может быть, ты просто долбаеб, и тебе не нужен никакой xhr, а тебе нужно просто сделать innerHTML = '<img src="url">', и тебе поставят пятерку, и повесят твою фотку рядом с остальными успешными студентами вашего пту.

мощный врыв

вообще есть мнение, что если сюда залетает чел с домашкой из вуза с криками помогите, то это априори долбоеб

Не априори. Но если ему отвечает тинплз, то такие больше не возвращаются.

По легенде отправляются на донбас.

двапой, если тебя местный император реабилитирует, ты не побрезгуешь остаться пданиться?

Не побрезгаю поссать ему на лицо.

Недавно кстати в тватторе видел что уже добавляют в браузерах асинхронную загрузку картинок. То есть вместо синхронного image.onload будут промисы. Ну и соответственно должно будет работать в отдельном треде браузера (а их там уже давно дохуя вроде как используется для других вещей).

Недавно кстати в тватторе видел что уже добавляют в браузерах асинхронную загрузку картинок. То есть вместо синхронного image.onload будут промисы. Ну и соответственно должно будет работать в отдельном треде браузера (а их там уже давно дохуя вроде как используется для других вещей).

Пригодилось бы такая хуйня для мобилок, пару лет назад. Как показывает моя практика мобилки вообще очень не охотно рендерят картинки любых размеров. И чем больше картинок тем сильнее будет тормозить интерфейс.

Сейчас, когда все ОСи кроме андроида и айоса подохли, а само железо стало весьма ничего, это мало на что будет влиять.

Кстати, оцените http://www.tizenexperts.com/2016/12/photofunia-native-app-comes-to-tizen/ - ради прикола написал перед новым годом приложение под тайзен, а все решили что оно нативное.

На самом деле писал не ради прикола. Писал ради tizenincentive где можно выиграть 10к долларов, если войдешь в топ 100. Мы вошли в топ 20 первые два месяца, а когда началась программа, мы не вошли и в топ 100. Так что 10к долларов я не увидел

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

И есть "нативная" версия для ubuntu mobile (touch). Апдейт для которой мы пытались запаблишеть раз сто. И система каждый раз выдавала новую ошибку, чисто по приколу. Но вроде победили. https://uappexplorer.com/app/photofunia-com.capsuledigital Только ОС спустя два месяца закрыли.

Алсо, я готовил чисто нативный апдейт под firefox os (мою любимую), в которой я каждый элемент ручками создавал (ну а зули вы хотели, 128мб ОЗУ это вам не это), и перед паблишем, стор для ффос тоже прикрыли. Поэтому мои старания были напрасны.

Вот и выходит, что я сделал много разных билдов, половину из них не запаблишел, а другая половина оказалась не востребована, потому что ОС закрылись.

Но мне похуй, мобильные приложения это как хобби. Фотофанией мы почти не занимаемся, она вроде стабильно работает на моем говнокоде.

Мы тоже мб будем делать мобильную аппу нашей хуиты, на каком-нибудь react native, но через год+ минимум. Сейчас пилим альфу нового фронтенда дашборда, с мини-бэкендом с graphQl (на фронте для этого юзаем Apollo, аля лайтовый Relay, ибо релэй это просто пиздец, проще сразу себе обе ноги прострелить на старте самому). Как запилим первый прототип, начнутся оптимизации со всеми этими танцами вокруг вебпака (код сплиттинг по раутингу, асинхронная подгрузка компонентов, умное кеширование и так далее).

Сегодня читал эту статью https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31 про ПРАВИЛЬНУЮ настройку кеширования вендор (и подобных) чанков. Я так ржал с этой хуйни, лучше любой комедии. Просто бесконечная череда сюжетных поворотов и роялей в кустах.

мощный врыв

вообще есть мнение, что если сюда залетает чел с домашкой из вуза с криками помогите, то это априори долбоеб

я спрашивал совет а не код  

в пту прокатило бы, а так скорое всего пошлют нахуй