ну я не сказал бы :) я целый год ходил на интенсивные курсы, и толк с них был.
по крайней мере, мне как технарю системный подход на курсах был куда ближе, чем рандомная болтология на уровне «твоя моя» с финнами.
Мне показалось, что смена работы у них не очень актуальна, поскольку общество очень устоявшееся, и рассчитывать на резкий рост зарплаты в другой фирме не приходится. Соответственно, работу меняешь, только если хочется сменить сферу деятельности.
Кстати, банальный поиск в гугле «imdb music» выводит интересные результаты — от сайтов-аналогов (ну, они так себя называют или пользователи их так расценивают) до дискуссий на тему, почему таких сайтов нет и не предвидится.
Слушайте, ведь здесь все айтишники. Если здешние люди жалуются на хамство и очередь, это означает лишь то, что интернет-банкинг недостаточно хорош (а иначе зачем вообще ходить в отделение?) Пусть хотя бы нетбанк доведут до ума.
Ну если так рассуждать, то и доступен этот контент тоже должен быть только на территории США.
Мне кажется, тут проще. Если я музей, то я допускаю людей фотографировать картины на моих условиях, каким бы то ни было законодательство, а если они не согласны — сессия не состоится.
А зачем вообще ссылка на решение американского суда? Ведь в Гугле лежат фотографии не только из американских музеев; у музеев вне США могут быть совершенно иные соображения.
Устоявшаяся терминология (даже корявая) — это уже кое-что.
Я помню времена, когда в некоторых программах пункт save file переводился как «спасти файл», и ничего, жили ;)
Да бросьте, человек просто использует аналогии, чтобы стала ясна позиция (в стиле «пиратство — это воровство», хотя любому ясно, что пиратство — это пиратство, а воровство — это воровство). Если вам не нравится термин «оккупация», придумайте другой термин.
Чтобы понять, что нынешняя власть не занимается тем, чем ей положено по должности, достаточно посмотреть ленту новостей. Ну например, чем занималась милиция в Кущёвской или как успешно службы убирали снег зимой в Москве и в СПб.
Я видел в одном месте прикольную доску со встроенным проектором. Проектор был установлен в верхней части доски и светил в кривое зеркало, которое аккуратно разворачивало изображение чётко на доску. Очень впечатлил механизм. При этом отображение происходит под очень острым углом, чтобы его загородить собой, надо прижаться к доске вплотную.
Так что можно сделать приличное решение и на основе проектора.
Понимаю, поэтому и спрашиваю :) У меня нет большого опыта промышленной работы, поэтому мне трудно взвесить реальные риски того или иного решения. Когда мне приходится писать такого рода класс, каждый раз прохожу примерно такой путь:
Первая мысль. Сделаем быстро! Есть уже классы комбо-бокса, списка и тому подобных гуёв. Запихну их всех в свои объекты и нечего думать, пусть у меня будет ComboBox* mNumber вместо int mNumber + внешний ComboBox.
Вторая мысль. Класс уже не будет библиотечным, т.к. он привязан к конкретному гуи. Проще переписать класс при надобности или делать его изначально переносимым — чёрт знает.
Третья мысль. Да меня ж товарищи распнут, если я засуну комбобокс в класс! Так никто не делает! Лучше уж сто функций синхронизации — да, жирно, зато по науке…
Меня в этом подходе смущает следующее:
(кратко) противоречие MVC.
(полно) «завязка» класса на GUI. Его сложнее сериализовать, он «тянет» за собой весь гуи фреймворк (становится тяжёлым), его придётся переписывать, если поменялся гуи фреймворк, да и непонятно что делать, если гуи пишет один человек, а класс разрабатывает другой.
В общем, мне это кажется шагом назад, хотя, конечно, сеттер уйдёт. Короче говоря, терзают смутные сомнения… :)
Немного не понял вот какую вещь.
Допустим, есть класс с целым параметром: class My { int mNumber; };
Я хочу управлять им через комбо-бокс. Пожалуй, я бы написал (нехорошо, понимаю) set функцию и вызывал бы её в OnComboBoxUpdate(). А вы предлагаете напрямую сделать так: class My { ComboBox* mNumber; };?
Или речь идёт лишь о том, чтобы поместить комбобокс в класс My, но всё остальное остаётся прежним?..
Такое давным-давно существует, называется «self-publishing», есть даже бесплатный вариант: www.unibook.com/
Суть: издательство печатает то, что вы ему подсовываете, и ваш труд оказывается в каталоге. Любой может эту книгу заказать через интернет, она будет оперативно напечатана и доставлена. Доходы — ну, в той или иной пропорции.
Удивительно, что все кассовые авторы ещё не перешли на эту модель. Видимо, совсем дурные. А может, не так всё просто, а?
1) конечно находит, это часть его работы
2) хороший вопрос — в принципе, такое есть, но проще натренировать на русских примерах готовый generic парсер
3) да, это и есть неоднократно упоминаемые «трибанки» — для английского penn treebank, для русского корпус syntagrus.
по крайней мере, мне как технарю системный подход на курсах был куда ближе, чем рандомная болтология на уровне «твоя моя» с финнами.
Мне кажется, тут проще. Если я музей, то я допускаю людей фотографировать картины на моих условиях, каким бы то ни было законодательство, а если они не согласны — сессия не состоится.
Я помню времена, когда в некоторых программах пункт save file переводился как «спасти файл», и ничего, жили ;)
Чтобы понять, что нынешняя власть не занимается тем, чем ей положено по должности, достаточно посмотреть ленту новостей. Ну например, чем занималась милиция в Кущёвской или как успешно службы убирали снег зимой в Москве и в СПб.
Так что можно сделать приличное решение и на основе проектора.
Первая мысль. Сделаем быстро! Есть уже классы комбо-бокса, списка и тому подобных гуёв. Запихну их всех в свои объекты и нечего думать, пусть у меня будет ComboBox* mNumber вместо int mNumber + внешний ComboBox.
Вторая мысль. Класс уже не будет библиотечным, т.к. он привязан к конкретному гуи. Проще переписать класс при надобности или делать его изначально переносимым — чёрт знает.
Третья мысль. Да меня ж товарищи распнут, если я засуну комбобокс в класс! Так никто не делает! Лучше уж сто функций синхронизации — да, жирно, зато по науке…
(кратко) противоречие MVC.
(полно) «завязка» класса на GUI. Его сложнее сериализовать, он «тянет» за собой весь гуи фреймворк (становится тяжёлым), его придётся переписывать, если поменялся гуи фреймворк, да и непонятно что делать, если гуи пишет один человек, а класс разрабатывает другой.
В общем, мне это кажется шагом назад, хотя, конечно, сеттер уйдёт. Короче говоря, терзают смутные сомнения… :)
Допустим, есть класс с целым параметром: class My { int mNumber; };
Я хочу управлять им через комбо-бокс. Пожалуй, я бы написал (нехорошо, понимаю) set функцию и вызывал бы её в OnComboBoxUpdate(). А вы предлагаете напрямую сделать так: class My { ComboBox* mNumber; };?
Или речь идёт лишь о том, чтобы поместить комбобокс в класс My, но всё остальное остаётся прежним?..
Суть: издательство печатает то, что вы ему подсовываете, и ваш труд оказывается в каталоге. Любой может эту книгу заказать через интернет, она будет оперативно напечатана и доставлена. Доходы — ну, в той или иной пропорции.
Удивительно, что все кассовые авторы ещё не перешли на эту модель. Видимо, совсем дурные. А может, не так всё просто, а?
2) хороший вопрос — в принципе, такое есть, но проще натренировать на русских примерах готовый generic парсер
3) да, это и есть неоднократно упоминаемые «трибанки» — для английского penn treebank, для русского корпус syntagrus.