abroabr

Здравствуйте формчане, совсем в депрессию упал. Не понимаю,что со мной не так, просто не могу заработать на фрилансе.

Уже 1.5 года изучаю вёрстку, начало получатся что-то нормальное (www.master-web.zzz.com.ua).

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

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

А на фрилансе начинать.... 5-7 лет фриланса = 2 года очно в конторе с сильными коллегами-профи.

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

При открытии автовход по уже известным логину и паролю + скрыть из трея.

Это незаконно такие заподлянки делать пользователю.
Но да, сие возможно, прямой посылкой сообщений в окно программы.
Как сделать незаконные вещи - здесь нельзя справшивать.

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

На деле это проще, чем выглядит.

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

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

Внешнее соединение обозначает, что помимо того, что вам выдало бы внутренее соединение вы дополнительно плюсом получите данные из первой (left join) или второй (right join) таблицы. Даже если в другой таблице и не было записей, соответствующих условию соединения.

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

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

Ответ на этот вопрос:

Как в GOlang указать в функции что возвращаемый тип будет либо массив, либо еще что то

Go - язык со статической типизацией.

Вам нужно или явно преобразовать.
Или использовать interface{} - но не рекомедуется этим злоупотреблять.

Ответ по приложенному вами исходному коду и тексту ошибки:

Но проблема у вас в другом.
Вы объявили переменные "b" и "err" внутри блоков

if {
} else {
}

Соответственно снаружи блоков этих переменных не видно.

Полнотекстовый поиск устроен достаточно примитивно.
У всех. Разница только в нюансах.

1. Делится текст на отдельные слова, отбрасываются короткие и служебные слова.
2. Прогоняются слова через стемминг (отсекаются окончания) snowball.tartarus.org/algorithms/russian/stemmer.html
3. По словам строится индекс что-то типа такого roaringbitmap.org

Все - MySQL, PostgreSQL, SphinxSeach, ManticoreSearch, ElasticSearch - работают по такому алгоритму, когда речь идет о полнотекстовом поиске.

Качество поиска упирается в основном в п. 1 и 2. Плюс ручная заточка (дополнительный словарь и пр.)
Скорость поиска упирается в п. 3.

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

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

MySQL и PostgreSQL - не имеют никаких преимуществ ни по скорости (как Sphinx/Manticore) ни по объему индекса (как ElasticSearch). Их преимущества - простота использования, если у вас данные изначально хранятся в реляционной СУБД.

Нет, выхлопа по скорости при переходе на MySQL c Sphinx вы не получите. Sphinx быстрее. От заточен именно на скорость.

Другое дело, что, возможно, вам не понадобится столь высокая заточенность на скорость у Sphinx. Возможно, удобство хранения в реляционной СУБД MySQL перевесит.

И да, непонятно зачем вам MongoDB. SphinxSearch уже давно может хранить и сами данные, а не только сам поисковый индекс. Дополнительное обращение к MongoDB после того как документ уже найден в SphinxSearch - снижает производительность. Возможно, MongoDB удобна для каких-то видов работ, например, для инициации построения полнотекстового индекса. Но собственно в процессе полнотекстового поиска - она лишнее звено.