КОТ++
Прикладное программирование
Системное программирование
Программирование микроконтроллеров

Программирование — это не наука, а ремесло. (c) Ричард Столлман

Опубликовано
Комментарии 0

АААААААААААААА блять сколько можно требовать от человека всё что угодно, сопровождая требования фразой: «ТЫЖ ПРОГРАММИСТ»?! Я думаю, что все уже поняли о чём пойдёт речь в данном посте. Готовьтесь пост взорвёт ваши пуканы. Хотя может бомбанёт только мой. Да, скорее всего взорвётся только у меня.

Я думаю, что все эти удивительные ситуации со сказочными требованиями к программистам идут от непонимания того, кем является программист. Вернее от понимания, от понимания в IT чуть меньше чем нихуя. Так вот я исправлю эту проблему раз и навсегда. Программист – это тот кто пишет блядский код, он блять программирует, программы делает. Он не взламывает злоебучую, безумно глючную, бело-синию соц. сеть, не занимается установкой ОС и программ, не продаёт компы, не чинит компы, не собирает компы. Он блять просто пишет ёбаный код. Хотя не исключено, что всё вышеперечисленное он может делать, и это не значит что только этим программист и занимается целыми днями дома и на работе.

Бывает общаешься с кем-нибудь:
-Кем ты работаешь?
-Программист
-Всего-то
-ЧТО ВСЕГО-ТО?
-Винду устанавливаешь
(БЛЯТЬ, неужели многие думают, что кодеры это такие люди, которые на работе целыми днями винду ставят, это же сколько компов нужно, или он просто на один и тот же комп весь день ставит и сносит винду, ставит и сносит)

-У меня комп не работает почему-то
-И что?
-Почини, ты ж умеешь
-Во-первых я не экстрасенс, а во-вторых не чиню я ебучие компы
-ПОЧЕМУ O_O
(действительно нахуй почему же? O_o)

-Посмотри эту страничку ВК
-Зачем?
-Ну достань инфу из сообщений
-Какую ещё блядскую инфу?
-Ну взломай, ты же можешь, программист же
-ААААААААААААААААААААААААААААААААААА, уйди от меня, не общайся больше со мной

Что же с этим можно сделать и как исправить все эти недоразумения? Покажите им этот пост, если не помогло, то нахуй не общайтесь с этими динозаврами! На сем завершу, всем пока!

Теги , ,
Автор

Опубликовано
Комментарии 0

Не так давно передо мной стояла серьёзная задача парсинга данных с некоторых сайтов. Проблема была в том, что обычный HTTP запрос не поможет, т.к. нужно, чтобы на странице отработал javascript и построил данные на странице, чтобы мы потом их спарсили. С помощью обычного HTTP запроса возвращается почти пустая страница. Выход очевиден - делать запрос через браузер, ждать пока отработают скрипты на странице и передавать исходный код уже сформированной страницы парсеру. Долго я гулял по гуглу прежде чем найти рабочее решение поставленной проблемы. Поэтому хочу поделиться с вами тем, что в итоге у меня получилось. Ниже привожу фрагменты кода с ключевыми моментами.
webView.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new MyJavaScriptInterface(), "HTMLOUT");
//нужно, чтобы загружалась полная версия сайта, а не мобильная
webView.getSettings().setUserAgentString("Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0"); 
webView.setWebViewClient(new WebViewClient()    
{
    @Override
    public void onPageFinished(WebView view, String url)
    {
        webView.loadUrl("javascript:window.HTMLOUT.processHTML('<html>'+"
        + "document.getElementsByTagName('html')[0].innerHTML+'</html>');");
    }

    @Override
    public void onReceivedError(WebView view, int errorCode, String description, String failingUrl)
    {
        super.onReceivedError(view, errorCode, description, failingUrl);
    }

	@Override
    public boolean shouldOverrideUrlLoading(WebView view, String url)
    {
        view.loadUrl(url);
        return true;
    }
});

private class MyJavaScriptInterface
{
    @JavascriptInterface
    public void processHTML(String html)
    {
        onPostExecute(html); 
        webView.stopLoading();
    }
}

public void execute()
{
    webView.loadUrl(url + urlQuery);
}
Методы execute и onPostExecute названы так, чтобы с получившимся классом можно было работать также как и с AsyncTask. Логика кода выше такая: браузер сообщает нам, что закончил свои дела по загрузке в событии onPageFinished, но теперь нам надо забрать исходный код страницы из браузера. Для этого прикручиваем JavaScriptInterface также как в коде выше. На stackoverflow.com находились различные вариации реализации этой хитрости, но почти ни один пример не работал. В каких-то тайных уголках гугла удалось найти решение и реализовать его, вот теперь делюсь хитрым приёмом с вами)

Теги , , ,
Автор

Опубликовано
Комментарии 0

В очередной раз хочу поднять тему NIH (not invented here) синдрома в программировании. Многие люди в том числе и я склонны к тому, чтобы каждый элемент проекта был разработан с нуля и своими руками. Это чревато беспричинно большими затратами времени, а также собственная разработка чаще всего не проходит должного тестирования. В итоге получается проект на который было затрачено уйма времени, т.к. разработчики писали помимо основного кода ещё и собственные движки и библиотеки, а он ещё и глючит.

Но у синдрома неприятия чужой разработки есть и свои плюсы. Программист, который «болен» NIH синдромом в процессе написания велосипедов досконально начинает разбираться в том как что работает получше своих коллег. Но это не значит, что всегда нужно делать все с 0. Потому как лепить велосипеды – это не единственный способ узнать, как работает тот или иной движок и пр. К тому же давайте тогда и компьютер свой с 0 сделаем. Ведь тот компьютер, которым мы пользуемся это чужая разработка, придётся свой изобретать.

Каждый раз, когда в проекте встаёт выбор между написанием своей библиотеки/движка и выбором уже существующих решений, очевидный вариант это определить, что будет быстрее: написать свою либу или освоить чужую. Могут быть разные ситуации, может даже случиться так, что придётся исправлять ошибки в чужой библиотеке (если она опенсорс). Но это в случае, если вам важны ваши времязатраты. Если же вас интересует делать все самому, то лучше делать самому, только сильно не увлекайтесь. Это опасный путь, можно случайно начать разрабатывать свою ОС.

Теги ,
Автор

Опубликовано
Комментарии 0

Туки-Тук – это удобный сервис для поиска и предоставления доступного жилья в короткие сроки.

Функционал:
- регистрация;
- верификация аккаунта по email и телефону;
- создание объявления о сдаче жилья в аренду;
- поиск объявлений по различным параметрам;
- бронирование объявлений;
- возможность выбор наилучшего кандидата для снятия жилья;
- рейтинги и отзывы.

Ссылка на сайт: http://tuki-tuk.com
Ссылка google play: https://play.google.com/store/apps/details?id=com.varvar.tuki_tuk

Теги ,
Автор

Опубликовано
Комментарии 1

Используете много картинок в своём андроид приложении? И при этом бывает вылетает ошибка OutOfMemory связанная с показом картинок? В таком случае этот пост для вас.

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

На stackoverflow.com предлагали ужимать картинки, а потом выводить на экран. В принципе неплохое решение, но чтоб отобразить сразу много картинок нужно применить 7/10 шакалов ко всем картинкам.

Также видел совет по увеличению хипа для приложения, прописать в манифесте:

android:largeHeap=«true»

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

Остаётся заюзать какую-нибудь библиотеку для подгрузки изображений из инета. На слуху у меня две таких либы: Picasso и Android-Universal-Image-Loader. Мне по некоторым причинам больше приглянулась вторая либа. Её то и попробуем использовать. Подключим в свой проект и пропишем код инициализации. Мне наиболее оптимальным кажется такой вариант (некоторые параметры были найден уже не вспомню на каком форуме):

        Executor downloadExecutor = Executors.newFixedThreadPool(5);
        Executor cachedExecutor = Executors.newSingleThreadExecutor();

ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE); int memClass = am.getMemoryClass(); final int memoryCacheSize = 1024 * 1024 * memClass / 8; options = new DisplayImageOptions.Builder() .showImageOnLoading(R.drawable.ic_stub_image) .bitmapConfig(Bitmap.Config.RGB_565) .imageScaleType(ImageScaleType.IN_SAMPLE_INT) .cacheInMemory(true) .cacheOnDisc(true) .build(); File cacheDir = StorageUtils.getCacheDirectory(this); ImageLoaderConfiguration config = new ImageLoaderConfiguration.Builder(getApplicationContext()) .taskExecutor(downloadExecutor) .taskExecutorForCachedImages(cachedExecutor) .memoryCache(new UsingFreqLimitedMemoryCache(memoryCacheSize)) // 2 Mb .diskCache(new LimitedAgeDiskCache(cacheDir, 52428800)) .imageDownloader(new BaseImageDownloader(this, 5 * 1000, 30 * 1000)) .defaultDisplayImageOptions(options) .build(); ImageLoader.getInstance().init(config);

Далее скачиваем и показываем картинку:

ImageLoader.getInstance().displayImage(imageUrl, imageView, MainActivity.options);

Но позже выясняется, что такой вариант особо не спасает. В логах у нас также будет OutOfMemory. А что если грузить сначала превьюшки для изображений (т.е. сжатые маленькие картинки), а если юзер просматривает картинку полностью, то в этот момент подгружать уже оригинал? Попробуем (код для подгрузки превьюхи):

ImageLoader.getInstance().displayImage(imageUrl, imageView, new ImageSize(80, 80));

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

Данное решение не оптимизирует работу приложения так, как хотелось бы одержимому перфекционисту, но вполне побеждает OutOfMemory!

Теги , ,
Автор

| 1 | | 4 | 5 | 6 | 7 | 8 |