Григорий Васильков

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

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

А/Б тестирование так называемое - это про то, сколько человеков купит в зависимости от того или другого элемента на сайте. Понятно, что А/б тестирование проще сказать, но вообще попроще базар, когда вопросы, очень прошу, и так простых людей мало осталось, и все делают вид, что не понимают - почему кризис.

В общем суть такая - для того, чтобы сделать тесты - тебе по сути не нужны сторонние платформы типа гугла или яндекса. Просто с ними проще статистику вести.

Твой программер попросту говоря ставит условие в сайте:
1. если время с 8 утра до 8 вечера - показать один вид, иначе другой вид
2. на кнопках висит какая-нибудь utm_ метка для того же яндекса или банально факт нажатия самим же программистом пишется в любое хранилище - базу, файл, что хочешь

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

б) возраст - меняется человек с возрастом, меняется, чтобы не трындели психологи, взрослый человек понимает, что наебывают все и всегда, хотя существуют отдельные люди которые т.н. "просто живут" и ведутся на 90% скидку как дети

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

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

Вот так это работает как-то.

В зависимости от степени безопасности.

Если разбить все это на "по-проще", общий принцип такой:

Клиент:
- в первый раз ввести строку текста
- нажать отправить
- больше не вводить, ибо лентяй, а мы ж ему продавать собрались, не дай бог он сука дискомфорт почувствует

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

Локальных хранилищ тоже бывает куча целая:
- кукисы (хранится прямо в браузере указанное время)
- сессии (хранится на сервере, но в кукисах есть ключ к ячейке в "банке", который опять же могут угнать)
- ... еще десятки способов, о которых знают только крутые кодеры, которые считают себя крутыми просто потому, что их знают, на деле с точки зрения создания ценности людям - бесполезные знания

Как ты понимаешь, это иллюзия безопасности, а не гарантия.

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

Вот еще тема, которую василий сказал - шифровать пароль уже на стороне клиента в момент отправки формы яваскриптом. Представьте себя хакером. Вы получили пакеты какого-то чувака, поставили компьютер на расшифровку, подключив десяток видеокарт, расшифровываете пароль, а вместо него видите 64 символьный хеш, ну то есть он прямо от клиента таким вышел. После этого будут маты от того, что теперь массив видюх нужно заставить еще и ключевую фразу из хеша выдрать. Ну то есть еще время декодирования увеличивается. Если загнаться то хеш может быть не просто хешем md5() а например md5 от md5 от развернутой строки прибавленной к md5() прямой строки, прокинутой через побитовый сдвиг на один разряд - ну то есть даже в этом закодировать последовательность действий. При отсутствии https - наиболее надежный способ.

И потом - программисты Yii не рекомендуют использовать фунцию md5(). Почему? Потому что она быстрая очень. И при переборе пароля массивом видеокарт перебирается он шибко быстро. Поэтому рекомендуют использовать hash функцию, которая для создания хеша использует побольше времени, несколько секунд скажем. При написании синхронной программы (сайта на php, например) - это заставит юзера подождать после регистрации секунды 3-4 лишних, но если загнаться то процесс генерации пароля можно запихнуть в асинхронщину, а пользователю сразу токен выдать, то есть пароль ему сгенерируется чуть позже. Таким образом - за счет более длинной хеш-функции по времени хакеру потребуется куда больше времени - то есть юзеру на прямое создание пароля 5 секунд, а хакеру на перебор нескольких миллионов паролей понадобится несколько лет. Никто ему не заплатит 10 косарей баксов, чтобы сломать ваш долбанный пароль ВКонтакте. Если банковская сфера - опять же как писал выше - хеш от хеша, да развернуть пару раз, да трижды порубить, потом постучать в бубен и все это в хеш еще раз и вуаля - декодирование пароля займет 100 лет.

Еще значит, При малейшем намеки на несоответствие токена или внезапное изменение - сервак говорит "тю, дядя, давайка пройди второй этап авторизации, а то я не верю, что это реально ты" и просит приложить палец. Или ввести номер, получив СМС. Или вставить ключ-карту синюю (duke nukem hello). Но и тут есть взлом - ключ карту украсть, смс-ку - попросить телефон, приложить палец = отрубить руку, вырвать глаз и тд

Тут к тебе на помощь приходит https. Https это такая штука, которая в двух словах может быть названа игрой в партизан. На войне играли так - когда радиопереговоры прослушивались, а шифраторов не было - единственным средством защиты - было использовать ошибки в тексте и матерные слова.

Так и тут - данные отправляемые в виде нулей и единиц. Компьютеры их так же легко перекодируют в пароль, как и закодировали. Чтобы этого не было, придумали ШИФРОВАТЬ строку в одну сторону. У сервака есть трафарет, у пользователя другой трафарет. Сервак шифрует своим, но назад можно расшифровать только пользовательским. Вернее можно и сторонним конечно, но современные компьютеры сделают это за много лет, и потому никто не заморачивается особо, производительность не та.

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

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

Я сейчас с тебя буду доплату брать за то, что ты бизнесом занимаешься, а не программированием. Ишь ты нео-бизнесмен какой пошел.
Вежливо спроси что за дела, и откалибруй - врет или нет. Если врет - посылай. Если беда дома - помоги. Так работать надо. А не по-еврейски - побольше сэкономить на своих сотрудниках, чтобы побольше подарить ленивым клиентам.

Мое мнение - что от этого нужно избавляться.
Если у тебя в фирме 1000 менеджерят, которые ничего не делают, а работать умеют только через CMS, вернее через нее тоже не умеют, но говорят что им надо - то это имеет смысл.

Уже давно картинки у нас лежат просто по внешнему коду товара (будь то код 1С или поставщика или присвоенный скриптом) - и лежат просто в одной папке. Когда находим товар без картинки - переименовываем и закидываем. А дальше твой сайт делает ресайз картинок, и по названию исходной фотки он всегда может проверить - есть ли кешированный мелкий размер и выводит его.

Для менеджерят пишется инструкция, что дескать переименовывать и вот форма - выделил из моего компьютера, перетянул. Скрипт после закачки записывает кто и когда.

Безусловно, можно сэкономить немного памяти на том, чтобы не получать из пути/имени новое кешированное имя каждый раз - и записать это в любую таблицу - будьто БД, эксель, json и вообще как угодно сохранить. Но тогда будет тратится время на поиск в этой таблице.

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

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

Ну можешь еще 10 языков изучить.
Или осознать, что бизнесу нужны:
а) твои понты
б) твои сертификаты
в) твоя возможность никогда не сознаться, что ты чего-то не знаешь
г) гарантия, что ты не будешь выпрашивать повышения оклада

В каждом из этих пунктов можно спотыкаться, но за это придется страдать.

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

Например, в Битриксе при добавлении элементов через админку или апи автоматически заполняется целая куча полей и если самому это вручную делать - можно уехать крышей.
В то же время АПИ битрикса не упрощает, а даже усложняет доступ к БД - твой код становится даже сложнее, чем писать SQL запрос. Поэтому все равно прибегаем к хитростям вида "запросить SQL-ом, закачать через Апи"

Касательно твоего примера мы наблюдаем в Опенкарте практически чистый SQL и потому нет разницы - будешь ты его импортировать через собственное подключение к бд, не забывая экранировать спецсимволы, или будешь использовать Опенкарт, который бесплатный, а значит ни за что не несет ответственности и вполне вероятно, что там такие проверки тоже не делаются, что делает потенциальную дыру для взлома.

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

Вопрос в том - хочешь ли ты быть виноватым в том, что кто-то унес все клиентские данные, или проще перекинуть это на другую компанию? Это вечная дилемма между учеными и бизнесменами. Одни хотят потестировать все и несмотря на ошибки - внести исправления, другие хотят никогда не быть виноватыми, и потому любой повод будут использовать чтобы поиметь с тебя денег.

И этому радостно подпевает голливуд, рассказывая, что из-за ученых злобные вирусы заражают человечество, поэтому в нашем мире лучше дескать вообще нихрена не делать, а только ждать пока само сделается. А оно, как ни странно, не сделается.

Присмотрись к своему заказчику. Если в нем нет ощущения, что нужно попробовать, прежде чем делать, а есть только "сделай мне и побыстрее" - я бы лучше ему спел песню про то, что надо покупать другие компании, пусть это будет его проблемой - иски, суды, чем твоей - что из-за тебя взломали сайт, а разве может быть иначе в их голове?

Бизнес в целом это всего три понятия:
1) деньги принадлежат хитрым, а не умным. Это разные вещи.
2) никогда не будь виноватым, твой авторитет и внешний вид важнее любой работы, которую никто не увидит, поэтому лучше не делай ничего, а всегда имей крайнего
3) если ты видишь, что кто-то упал, помоги ему сломать побольше конечностей, а всем расскажи, что "он же сам хотел упасть, а ты честно помог"

И это все достижимо только если самому не делать вообще ничего, а всегда иметь крайнего.

И понимая это, какими будут твои действия? С точки зрения логики - не работать на бизнес и на деньги. Но ведь это заставит тебя копать землю и растить для себя продукты, а значит бросить программирование... поэтому просто вливайся в колею и улыбайся, делая вид, что ты глупый и ничего не понимаешь.

Ты можешь что-то сделать с соединенным к тебе пользователем или оставившим свои данные.

1. IP-адрес
Если он сейчас ходит по твоему сайту - он открывает соединения с определенных IP. Можешь их заблокировать, но вместе с ним отвалится все компьютеры, которые ходили с его модема - а в некоторых компаниях 100 компов по одному роутеру сидят - забанишь сразу 100 человек. А крутой хакер использует прокси или анонимайзер и все равно попадет на сайт

2. Cookies
Вешание куки и запрет входа на сайт по куки. Способ для совсем уже новичков - 80% людей за 35 лет на постсоветском пространстве. Вешается клиентский параметр, который очищается через Chrome Console например. Но они не знают про ХромКонсоль - и будут получать отворот поворот.

3. Аккаунт
Если твой клиент зарегистрирован - ты можешь удалить его аккаунт. Эта система прекрасно работает в платных онлайн играх, где под логин система привязывается. Залочил аккаунт, а все остальные не могут системой пользоваться. Говняное решение для продаж, но наилучшее для платных сервисов. Реализовать сложнее, чем описать.

4. По чем-то еще
Сегодня существуют сервисы, выдающие информацию о привязанной страничке ВКонтакте, одноклассниках и чему угодно. Получая такую информацию от имени твоего сервера, можно блокировать чувака даже по этому. По номеру телефона, по любой информации, которую ты можешь о нем получить в данный момент времени. Вопрос в том, что это обходится все очень легко - на сайты ходится через прокси, телефон нигде не указывается, в конце концов включается режим инкогнито, который сделан специально для таких случаев - когда ты хотел бы быть абсолютным анонимом. В этом случае все что тебя спасет - IP адрес, но помни что у половины интернета провайдеры выдают его случайным образом, залочив сегодня и навсегда - ты запретишь вход не тому, кому хотел.

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

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

Как здесь очень разумно обьяснили:
Сам класс модели - это таблица
Экземпляр класса - это строка таблицы
Это звучит просто ровно до тех пор, пока у тебя не начинается несколько источников данных, в одни из которых ты можешь заливать, а в другие нет - в одних у тебя есть база, а в других это просто файл
Словом смысл в том, что паттерн MVC это как бог. Он вроде бы есть, но его настоящего никто не видел. С помощью него легко обьяснять как это работает, чтобы реализовывать придется запастись йодом и стальными орешками

Я сейчас тоже пытаюсь в этом разобраться и усовершенствовать, чтобы не перейти грань "я люблю паттерны и потому пишу на симфони", а остаться в "я люблю свою работу и потом пишу чтобы работало и курить маны было не нужно", но пока получается так себе

Вчера мне подсказал один господин очень интересное решение для этого непростого выбора

Почти наверняка вы выбираете - где лучше хранить данные и чтобы получить удобное обслуживание системы (без длинных SQL) и быстрый поиск результатов (который как раз лучше в SQL, ведь в случае с файлом придется всю "базу" в оперативку лить, а значит постоянно докупать планочки и пинать админов - дескать поставьте побольше, а то чето тормозит), второе опять же - массивы длинной в пару километров долго читаются и парсятся редактором, то есть что-то изменить "открыв файл" - будет трудно - придется это делать через API, а значит проблемы или гениальное АПИ.

Я пока остаюсь на реляционке, хотя гении типа Яндекса и Гугла давно делают все в файлах/nosql и наверняка есть ответ почему вида "если у тебя миллиард записей, сервак может тупо лечь".

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

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

В ближайшее время попробую такую комбинацию

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

Скрипт у меня где-то был который сравнивает удаленный массив с локальной копией и возвращает дельту изменений (массивы для прямой загрузки в бд) без потерь старых данных.

Ща я тебе скрипт скину погодь

// получаем локальное хранилище (тут может быть запрос в БД)
// * функция _pluck работает примерно как array_column только умнее - обрезает массив именованных массивов оставляя в каждом ключе значение только одной ячейки вместо всего массива, в underscore/lodash такая штука есть), вторым параметром принимает массив нужных полей (в нашем случае - null = весь массив без изменений), в третьем - колонку, которая станет ключом - то есть здесь получилось чтобы просто значения колонки code, сделали ключами
$full_arr = _pluck(json_decode(file_get_contents($this->full_path), true), null, "code");

// получаем удаленное хранилище (тут запрос на другой сервер, потом переназначение колонок, проверка минимального их количества, проверка значений данных)
$current_arr = $this->getData();


// получаем УДАЛЕННЫЕ товары
// - в товаре не хватает полей
// - товар с таким кодом когда-то был, а теперь исчез
// - количество товара меньше требуемого

// для этого
// 1. получить плохие элементы из текущей выгрузки
// 2. получить элементы, которые раньше когда-либо попадались, а теперь их почему-то нету
// 3. получить элементы, в которых количество меньше требуемого
// 4. проставить им флаг "удаленный"
// 5. в массив для синхронизации добавить только те удаленные, которые не были удалены раньше
$process_current_arr = array_filter($current_arr, function ($v) {

  // тут функция проверяющая наличие колонок для сравнения - ну то есть сравнение производится по такому-то набору колонок id, code, param1, param2, нужно убедится что эти колонки есть, в противном случае элемент ставится как плохой
  return $this->filterData($v);

});
$deleted_arr = array_diff_key($current_arr, $process_current_arr);
$deleted_arr = array_replace($deleted_arr, array_diff_key($full_arr, $process_current_arr));
$deleted_arr = array_replace($deleted_arr, array_filter($process_current_arr, function ($v) {
  return ($v["count"] < $this->count);
}));
$deleted_arr = array_map(function ($v) {
  $v["deleted"] = 1;
  return $v;
}, $deleted_arr);
$process_current_arr = array_diff_key($process_current_arr, $deleted_arr);
$sync_arr = array_replace($sync_arr, array_intersect_key($deleted_arr, array_filter(array_replace($deleted_arr, array_intersect_key($full_arr, $deleted_arr)), function ($v) {
  return (empty($v["deleted"]));
})));


// получаем ВОССТАНОВЛЕННЫЕ товары
// - товары которые были удалены, а теперь они соответствуют требованиям

// для этого
// 1. находим удаленные товары в нашем хранилище
// 2. методом исключения определяем, какие товары есть в нашей выгрузке
$recovered_arr = array_intersect_key($process_current_arr, array_filter($full_arr, function ($v) {
  return (!empty($v["deleted"]) && (strval($v["deleted"]) === "1"));
}));
$recovered_arr = array_map(function ($v) {
  $v["deleted"] = 0;
  return $v;
}, $recovered_arr);
$sync_arr = array_replace($sync_arr, $recovered_arr);
$process_current_arr = array_diff_key($process_current_arr, $recovered_arr);


// получаем НОВЫЕ товары
// - товары которых в нашем хранилище нету

// для этого
// 1. методом исключения по коду сравниваем хранилище и оставшиеся для обработки элементы
$new_arr = array_diff_key($process_current_arr, $full_arr);
$sync_arr = array_replace($sync_arr, $new_arr);
$process_current_arr = array_diff_key($process_current_arr, $new_arr);


// получаем ИЗМЕНЕННЫЕ товары
// - товары которые есть и в нашем хранилище и в выгрузке, но данные отличаются

// для этого
// 1. методом соответствия по хешу сравниваем хранилище и оставшиеся для обработки элементы
// * hashData - функция которая отбирает из массива значения нужных колонок и по ним делает хеш, не учитывая остальное
$process_current_arr_md5 = array_combine(array_map(array($this, "hashData"), $process_current_arr), $process_current_arr);
$full_arr_md5 = array_combine(array_map(array($this, "hashData"), $full_arr), $full_arr);
$updated_arr = _pluck(array_diff_key($process_current_arr_md5, $full_arr_md5), null, "code");
$sync_arr = array_replace($sync_arr, $updated_arr);
$process_current_arr = array_diff_key($process_current_arr, $updated_arr);


// Соединяем старые данные с новыми, чтобы ничего не потерять
$filemtime = date("Y-m-d H:i:s", filemtime($this->sync_path));
$sync_arr = array_replace(array_intersect_key($full_arr, $sync_arr), $sync_arr);


// Тут в конце соединяем наш full и sync, сохраняем или просто sync выводим, чтобы увидеть отличающиеся записи в прайсе и бд

Попробуй потестить может какие глюки найдешь, то я тоже исправлю

Непростая, но реализуемая.

Я бы хранил смещение от начала дня чтобы задать время отправления/прибытия в конкретный день

Храните где угодно - это не принципиально, ваш код модели должен уметь получить данные из того файла где ВАМ удобнее хранить
БД реляционная результаты выдаст быстрее и для диплома здесь бы хватило с крышей
Захотите вывести в таблицу ворда или чего еще - это уже чуть другая задача
Считывать из ворда / экселя - бред - долго читать, долго комбинировать, долго искать, а еще надо будет кешировать, оптимизировать - нафиг надо.

Для диплома запользуйте реляционную БД которую знаете.

Вы храните маршруты с временем прибытия/отправления, временем в пути, временем стоянки и все что необходимо в таблице "маршруты".

К маршрутам привязываются станции, где будут остановки.

Если человек хочет уехать сегодня - он выбрал метку времени, выбрал свою станцию, выбрал куда хочет попасть.

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

Задача не из простых, но когда сделаете сможете чуть ли не торговые маршруты считать, задача продается людям которые часто сигают через границу в соседнюю страну за покупками, задача продается игроманам космических игр, задача продается компаниям типа яндекса, но они не купят, у них своих головастиков с крышей.

Лучше б директором его быть обучил, хоть все красиво в жизни будет

А блин сорян, оставлю у кого еще вопрос возникнет
992 - 16 * 2 = 960 / 12 = 80

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

Обертку, ей overflow:hidden (там самым мы говорим "скрыть все что за границами блока")
На событие scroll, mwheelup, touchmove вешаем обработчик который меняет top: вложенного блока.

Глючить будет страшно.

h1 - блочный элемент и растягивается он на всю ширину любого родителя
если h1 "торчит" - значит родитель его не ограничивает.

блоку text можно задать overflow hidden, чтобы спрятать все за его пределами
он все равно будет показан в chrome console полноразмерным, но по факту его видно не будет, поскольку родитель его спрятал

в вашем случае у блока h1 стоит line-height: 0.5 что значит "пол-размера шрифта". Если там шрифт 200 размера, то высота в 100 пикселей взявшаяся из ниоткуда - закономерна