Пользовался некоторыми вещами из перечисленного списка, но теперь использую Squirrel SQL для написания запросов в связке с обычной командной строкой для администрирования. Дешево и сердито.
Если могу написать краткий комментарий на английском, то пишу на английском. Если же не получается перевести, но комментарий важен (поясняет какую-то неочевидную вещь, либо просто очень нужен в этом месте), то напишу на русском и не буду париться. А так, конечно, если б мог все толково переводить, писал бы везде на английском.
Имхо незаконченное высшее — довольно хороший признак раздолбая. Потому что чтобы закончить вуз, необязательно даже что-то уметь — достаточно просто быть немного ответственным (ходить на пары, где отмечают, сдавать хотя бы как-то лабы и коллоквиумы, получать допуски). Есть, конечно, люди, которые ДЕЙСТВИТЕЛЬНО сознательно приняли решение не заканчивать институт (либо потому, что им это не нужно, либо по каким-то другим обстоятельствам), но таких людей сейчас единицы, и среди моих знакомых таких нет. Все, кто вылетели, — виноваты сами. Бегают сейчас, досдают-пересдают.
Такая же беда ) Сидел тупил над списком протоколов, попробовал даже провалиться в QIP-протокол (вдруг ICQ там где-то в подразделе) но как и предполагал — там квиповский джаббер.
Хочу заметить, что использовать ассерты для проверки входных данных public-функции — ошибка. Функция должна проверять аргументы в любом случае и корректно реагировать (либо бросать исключение, либо возвращать специальное значение, сигнализирующее о недопустимых значениях аргументов). Assert для проверки входных данных можно использовать только в private-методах (в том случае, когда вы точно знаете, с какими аргументами вызываете свой метод). Потому что срабатывание assert рассматривается как ошибка В КОДЕ ФУНКЦИИ а не в вызывающем коде, и если вы оставите public функцию с ассертом на входные данные, то потом будете лезть в функцию и искать ошибку там, где её нет, вместо того, чтобы проанализировать ArgumentException.
А она столь же проста как и дотнетовое API? Я толком не смотрел, но на первый взгляд классов там намного больше по сравнению с 2 классами DateTime, DateTimeOffset и одним енумом DateTimeKind. Утверждалось что при создании упрощенной модели появляются проблемы, а не то, что для этой задачи невозможно построить внятную объектно-ориентированную модель вовсе.
Да нормальное API. Проблем, конечно, с датами и временем куча, но эта сложность обусловлена объективной сложностью модели. Нельзя поверх сложной модели накрутить простое и непротиворечивое API. Что-то будет обязательно потеряно. Не стоит думать, что команда .NET с бухты-барахты написала этот код. Я уверен, что каждый метод, каждая деталь реализации была продумана тщательнейшим образом, с многочисленными спорами и обсуждениями в кулуарах.
А чтобы писать нормальный код, достаточно взять за правило хранить и передавать дату только в UTC (и все манипуляции арифметические тоже), а в локальное время переводить только при необходимости вывести её пользователю.
Это часть того, что называется в дотнете APM — asynchronous programming model. Классы, которые поддерживают асинхронное выполнение, должны следовать рекомендациям по их оформлению соответствующим образом. К примеру, если обычный метод назывался DoSomething, то его асинхронная версия должна быть парой методов BeginDoSomething/EndDoSomething. Begin-метод должен возвращать IAsyncResult, а End-метод принимать его в качестве аргумента.
А IAsyncResult вы можете реализовать как вы хотите (если вы делаете асинхронный API). Это не обязательно просто хранилище для хендла, в общем случае это объект, представляющий собой контекст выполняемой асинхронной операции.
От везения скорее зависит. Повезло к примеру наткнуться на полезную инфу в интернете — заинтересовался — пошел дальше шарить — произошло развитие личности. А если не повезло — так и остался неразвивающимся дурачком, живущим только чтобы покушать да поспать.
Не верю. В С++ намного более сложные синтаксические правила, чем в C#/Java. Перегрузка операторов, конструкторы копий, нюансы механики вызова функций и возврата значений (return const reference к примеру), константность, указатели на члены класса, friend-классы, множественное наследование, виртуальное наследование, — всего этого просто нет в C#/Java, поэтому и описание этих языков не может быть таким же большим, как С++.
rebase — это тот же merge, просто записывается в историю он так, чтобы история выглядела линейной. Поэтому разрешение конфликтов никто не отменял — если гит не сможет разрулить ваш конфликт автоматически, он попросит вас сделать это вручную.
Ну а вообще я бы рекомендовал перед любыми операциями, которые переписывают историю, делать копию вашего локального репозитория рядом (на всякий случай). Особенно если вы только что познакомились с rebase и еще не знаете, как отменить неудачный rebase, а плюс к этому всему в вашем репозитории много новейших коммитов, бакапа которых нигде нет.
— Форест, ты должен проверить безопасность SQL Server!
— Есть, сэр!
А чтобы писать нормальный код, достаточно взять за правило хранить и передавать дату только в UTC (и все манипуляции арифметические тоже), а в локальное время переводить только при необходимости вывести её пользователю.
А IAsyncResult вы можете реализовать как вы хотите (если вы делаете асинхронный API). Это не обязательно просто хранилище для хендла, в общем случае это объект, представляющий собой контекст выполняемой асинхронной операции.
Ну а вообще я бы рекомендовал перед любыми операциями, которые переписывают историю, делать копию вашего локального репозитория рядом (на всякий случай). Особенно если вы только что познакомились с rebase и еще не знаете, как отменить неудачный rebase, а плюс к этому всему в вашем репозитории много новейших коммитов, бакапа которых нигде нет.