понедельник, 21 июля 2008 г.
вторник, 10 июня 2008 г.
Идеи
Идеи возникают очень спонтанно. Вот только корни этой спонтанности уходят глубоко в долгие подсознательные размышления. Последние дни я очень долго думал над вопросом: что писать? Писать, т.е. программировать. Ведь программирование для меня не только работа, или учёба - это хобби и возможность отдохнуть. Особенно хорошо получается отдохнуть тогда, когда я программирую для себя - нет никакого определённого план-графика, никто не скажет, что программа выдаёт плохие результаты, нет надобности куда-то спешить, лихорадочно тестировать, писать отчёты...
Именно в такие моменты, когда я программирую для себя меня посещает программистская муза.
Вова был абсолютно прав, когда говорил, что в программистской среде нужно создать своё имя.
Для создания имени нужна идея. И её реализация :)
У меня появилась идея.
Осталось её реализовать.
Именно в такие моменты, когда я программирую для себя меня посещает программистская муза.
Вова был абсолютно прав, когда говорил, что в программистской среде нужно создать своё имя.
Для создания имени нужна идея. И её реализация :)
У меня появилась идея.
Осталось её реализовать.
пятница, 25 апреля 2008 г.
Отечественный поискпром
Затравка
Здравствуйте, гики!
Вы оба знаете, что меня веб всегда как-то интересовал (другое дело что ничего из этого не получилось), и интерес этот не пропал. Я и до сих пор читаю какие-то статьи на тему поиска в сети, и последнее время чаще отечественные статьи. Это потому, что, наткнувшись (не то слово; всё равно что сказать "наткнулся на слона") на один замечательный сайт я понял, что российская веб-общественность растёт и процветает.
Имя тому сайту Хабрахабр. Я писал как-то Володе о нём, не знаю, начали вы читать или нет. Ещё раз настоятельно рекомендую.
Пища для усвоения
Всем известны три российских поисковика: Rambler, Яndex и Mail.ru. Ну, и все они, конечно, знамениты не только тем, что умеют осуществлять поиск. Ну, я думаю, что не суть, как мы будем их называть, поисковиками ли, порталами ли, неважно. Ибо речь не об этом. А речь о том, какого в каждой из этих компаний работать и трудиться. Конечно же, интернет-направленность рассматриваемых компаний навеяна гиковостью =)
Предлагаю почитать обзоры людей, каким-то образом причастных к этим компаниям, и обладающих некими по этому поводу сведениями.
Rambler
Проект "Офис"/Офис Рамблера // Хабрахабр
Яndex
Работа в «Яндексе» // Работа.ru
Mail.ru
Работа в Mail.ru // От работника компании
Моё примечание: Последний материал, конечно, несколько сомнителен. Но, можно надеяться, что фотографии подделками не являются, и хоть по ним можно судить. Самый впечатляющий обзор, конечно, у Работы.ру.
А зачем, собственно?
Вы оба два программисты. В этих трёх компаниях набор сотрудников есть почти всегда. В Яндексе так вообще постоянно принимают. Вот Заур может и уезжает, а вот тебе, Володя, я бы настоятельно рекомендовал предъявить Яндексу свои силы. С/С++ программисты нужны там, да ещё какие-нибудь тоже наверняка нужны.
Постскриптум
Володя, ну, меня-то послушай? Я ж в Китае бывал, мне лучше знать =)
Здравствуйте, гики!
Вы оба знаете, что меня веб всегда как-то интересовал (другое дело что ничего из этого не получилось), и интерес этот не пропал. Я и до сих пор читаю какие-то статьи на тему поиска в сети, и последнее время чаще отечественные статьи. Это потому, что, наткнувшись (не то слово; всё равно что сказать "наткнулся на слона") на один замечательный сайт я понял, что российская веб-общественность растёт и процветает.
Имя тому сайту Хабрахабр. Я писал как-то Володе о нём, не знаю, начали вы читать или нет. Ещё раз настоятельно рекомендую.
Пища для усвоения
Всем известны три российских поисковика: Rambler, Яndex и Mail.ru. Ну, и все они, конечно, знамениты не только тем, что умеют осуществлять поиск. Ну, я думаю, что не суть, как мы будем их называть, поисковиками ли, порталами ли, неважно. Ибо речь не об этом. А речь о том, какого в каждой из этих компаний работать и трудиться. Конечно же, интернет-направленность рассматриваемых компаний навеяна гиковостью =)
Предлагаю почитать обзоры людей, каким-то образом причастных к этим компаниям, и обладающих некими по этому поводу сведениями.
Rambler
Проект "Офис"/Офис Рамблера // Хабрахабр
Яndex
Работа в «Яндексе» // Работа.ru
Mail.ru
Работа в Mail.ru // От работника компании
Моё примечание: Последний материал, конечно, несколько сомнителен. Но, можно надеяться, что фотографии подделками не являются, и хоть по ним можно судить. Самый впечатляющий обзор, конечно, у Работы.ру.
А зачем, собственно?
Вы оба два программисты. В этих трёх компаниях набор сотрудников есть почти всегда. В Яндексе так вообще постоянно принимают. Вот Заур может и уезжает, а вот тебе, Володя, я бы настоятельно рекомендовал предъявить Яндексу свои силы. С/С++ программисты нужны там, да ещё какие-нибудь тоже наверняка нужны.
Постскриптум
Володя, ну, меня-то послушай? Я ж в Китае бывал, мне лучше знать =)
воскресенье, 16 марта 2008 г.
Обманутый Proxy
Многие студенты нашего общежития страдают из-за небольшой (казалось бы) мелочи: интернет работает только через прокси-сервер. Доступны порты http (3128) и Socks5 (1080). Для большинства программ этого вполне достаточно. ВСЕ браузеры умеют работать через прокси, в настройках ВСЕХ IM-клиентов есть закладка "Network", где прописываются данные proxy. Но как обстоит дело с программами, которые через прокси не работают принципиально? Например, мой любимый почтовый клиент The Bat!. Другой пример: InfiniaChess - очень хороший клиент для игры в шахматы. Играть с его помощью я мог только дома (т.к. в дома у меня ADSL со всеми открытыми портами).
Как оказалось, у проблемы есть решение. Под OS Windows оно называется Proxifier. Proxifier перехватывает сетевые пакеты программы и пересылает их сквозь туннель. Тунеллируются в данном случае заголовки пакетов сеансового уровня.

Как оказалось, у проблемы есть решение. Под OS Windows оно называется Proxifier. Proxifier перехватывает сетевые пакеты программы и пересылает их сквозь туннель. Тунеллируются в данном случае заголовки пакетов сеансового уровня.

Программа, которая не умеет работать с прокси и не подозревает, что её сетевой траффик сначала проходит через proxifier и после перенаправляется на прокси-сервер указанный в его настройках. А настроить можно практически всё: какие программы тунеллировать, а какие нет; с каких и на какие порты перенаправлять траффик и.т.д.
Очень удобным решением Proxifier оказался в случае Skype'a. Последний очень долго соединяется через прокси-сервер (а если есть более прямой выход в интернет, Skype игнорирует настройки proxy). А как было сказанно выше, с включённым Proxifier'ом Skype отсылает пакеты думая, что работает напрямую с сетью.
Вот так были побеждены ограничения интернета в нашем общежитии :-)
Очень удобным решением Proxifier оказался в случае Skype'a. Последний очень долго соединяется через прокси-сервер (а если есть более прямой выход в интернет, Skype игнорирует настройки proxy). А как было сказанно выше, с включённым Proxifier'ом Skype отсылает пакеты думая, что работает напрямую с сетью.
Вот так были побеждены ограничения интернета в нашем общежитии :-)
пятница, 7 марта 2008 г.
Opera преподносит сюрприз
Мой любимый браузер "Opera" продолжает преподносить сюрпризы :-) Сегодня я обнаружил в её кеше файлы с расширением *.flv. A это - ни что иное, как Flash Video. Просмотрев эти файлы, я предположил, что механизм работы большинства онлайн-видео плееров выглядит следующим образом:
1) Загрузить плеер
2) Загрузить видео файл в кеш браузера
2.1) Грузить файл с места "ползунка" плеера до его конца
3) Проиграть файл из кеша
*) Процесс 2.1 идёт параллельно процессу 3
Примечательно в этой схеме то, что в кеше изначально выделяется столько места, сколько "весит" видео файл. Это происходит в начале 2-го этапа и не зависит от места, с которого этот файл будет проигрываться. При этом, в файле останется пустое место, в котором не будет никакой видео информации. Т.е. если вы хотите получить полный видео файл - дождитесь его загрузки в плеере (обычно по полосе прокрутки можно судить о том, какая часть файла была загружена, а какую ещё предстоит загрузить).
Данный подход успешно работает с видео из vkontakte.ru и loadup.ru :-)
Kеш браузера Opera находится в папке ..\profile\cache4\.. Профиль может лежать в разных местах в зависимости от системы и выбора вариантов установки. Чтобы избежать сложностей, лучше воспользоваться поиском папки "cache4" :-)
Успешного создания видео-архивов!
1) Загрузить плеер
2) Загрузить видео файл в кеш браузера
2.1) Грузить файл с места "ползунка" плеера до его конца
3) Проиграть файл из кеша
*) Процесс 2.1 идёт параллельно процессу 3
Примечательно в этой схеме то, что в кеше изначально выделяется столько места, сколько "весит" видео файл. Это происходит в начале 2-го этапа и не зависит от места, с которого этот файл будет проигрываться. При этом, в файле останется пустое место, в котором не будет никакой видео информации. Т.е. если вы хотите получить полный видео файл - дождитесь его загрузки в плеере (обычно по полосе прокрутки можно судить о том, какая часть файла была загружена, а какую ещё предстоит загрузить).
Данный подход успешно работает с видео из vkontakte.ru и loadup.ru :-)
Kеш браузера Opera находится в папке ..\profile\cache4\.. Профиль может лежать в разных местах в зависимости от системы и выбора вариантов установки. Чтобы избежать сложностей, лучше воспользоваться поиском папки "cache4" :-)
Успешного создания видео-архивов!
среда, 6 февраля 2008 г.
C++ Standard Library, UTF-8, UTF-16
На каникулах мне пришлось довольно глубоко влезть в стандартную библиотеку C++ и немного разобраться с кодировками путей файловых систем.
Летом я написал класс для чтения файлов двоичного формата. Для максимальной переносимости использовалась исключительно стандартная библиотека. Напомню, что вся работа с двоичными файлами в C++ должна проводиться при помощи классов-потоков вроде fstream. Объект класс fstream инициализируется конструктором вида(как и все классы этой группы):
fstream (const char *s, int)
Здесь const char* - C-строка, где располагается адрес файла, второй аргумент - флаги, определяющие режим доступа к файлу. Это - именно определенная стандартом конструкция и, полагаю, очень часто используется в различных библиотеках.
Напомню также, что в NTFS для записи путей к файлам используется Unicode (UTF-16). UTF-16 для хранения информации о символе использует два байта и не совместима со стандартной ASCII.
В этот самый const char* никак не записать путь, состоящий из символов UTF-16, адрес надо указывать именно в однобайтных символах.
Забавно получается! Стандартная библиотека языка поддерживает чтение многобайтных кодировок из файла, но не гарантирует открытие названий файлов многобайтных кодировок вроде UTF-16 в NTFS; и открываемый под Windows адрес обязательно должен состоять из символов ASCII.
Пары байт Unicode пройти как последовательность символов в памяти не могут, потому что в них могут встретиться нулевые с точки зрения C-строк последовательности, закрывающие строку.
UTF-8 же можно передавать в таких строках. Дело в том, что последняя варьирует число используемых байт от одного до четырех, сохраняя при этом обратную совместимость с 7-битной таблицей символов ASCII; гарантируется, что ни один из байтов не будет представлять собой закрывающий C-строку нулевой байт.
Получилось, что файлы с русскими символами в пути под Линуксом открывались, а под Виндой - нет, хотя я использовал средства из стандартной библиотеки.
Для совместимости пришлось переделывать мой класс под использование файловых дескрипторов C, одинаково работающих и в современных Линуксах, и в Видоусах.
Летом я написал класс для чтения файлов двоичного формата. Для максимальной переносимости использовалась исключительно стандартная библиотека. Напомню, что вся работа с двоичными файлами в C++ должна проводиться при помощи классов-потоков вроде fstream. Объект класс fstream инициализируется конструктором вида(как и все классы этой группы):
fstream (const char *s, int)
Здесь const char* - C-строка, где располагается адрес файла, второй аргумент - флаги, определяющие режим доступа к файлу. Это - именно определенная стандартом конструкция и, полагаю, очень часто используется в различных библиотеках.
Напомню также, что в NTFS для записи путей к файлам используется Unicode (UTF-16). UTF-16 для хранения информации о символе использует два байта и не совместима со стандартной ASCII.
В этот самый const char* никак не записать путь, состоящий из символов UTF-16, адрес надо указывать именно в однобайтных символах.
Забавно получается! Стандартная библиотека языка поддерживает чтение многобайтных кодировок из файла, но не гарантирует открытие названий файлов многобайтных кодировок вроде UTF-16 в NTFS; и открываемый под Windows адрес обязательно должен состоять из символов ASCII.
Пары байт Unicode пройти как последовательность символов в памяти не могут, потому что в них могут встретиться нулевые с точки зрения C-строк последовательности, закрывающие строку.
UTF-8 же можно передавать в таких строках. Дело в том, что последняя варьирует число используемых байт от одного до четырех, сохраняя при этом обратную совместимость с 7-битной таблицей символов ASCII; гарантируется, что ни один из байтов не будет представлять собой закрывающий C-строку нулевой байт.
Получилось, что файлы с русскими символами в пути под Линуксом открывались, а под Виндой - нет, хотя я использовал средства из стандартной библиотеки.
Для совместимости пришлось переделывать мой класс под использование файловых дескрипторов C, одинаково работающих и в современных Линуксах, и в Видоусах.
Подписаться на:
Комментарии (Atom)