kefirr

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

Это какая-то мерзенькая реклама. Я долго не мог одуплить, что происходит.

Вообще, сам факт написания кода при программировании отнимает менее 10% времени. Не думаю, что стоит так извращаться ради этих 10%. Лучше программируйте в транспорте путем обдумывания и продумывания алгоритма, функций, интерфейсов и т. д. Чтобы, по приезду, только осталось перенести листинг из головы на компьютер.

Лучше читайте дальше, пользы будет на много больше.

юзал флешки для системы, тут важен вопрос оптимизации работы, отключение логов, перенос всех часто читаемых файлов на нормальный диск.
Без оптимизации почти все флешки умерли в течении полугода(штук 10 было).

У меня вот такой вот сервачок:
www.citilink.ru/configurator/q497285/

Больше всего шумит БП, но он в целом тихий.
На балконе так вообще не слышно. Из ваших пунктов предлагаю 2. SSD;

habrahabr.ru/blogs/hr/117589/
Все ответы давно даны :)

Чтобы беречь зрение, нужно найти причину по которой оно ухудшается. Их несколько по сути:

* Физиологические особенности организма (люди с панкреатитами и диабетами имеют физиологическую предрасположенность к близорукости). Тут ничего не попишешь, зрение будет ухудшаться, нужно поддерживать его и черникой, и витаминами, и другими средствами
* Пересыхание глаз из-за длительного отсутствия моргания. Начинается воспалительный процесс, который на себя забирает и так слабый поток кислорода и питательных веществ. Питание глаз идет после головного мозга, и им часто, при интенсивной работе, банально не хватает кислорода. Токсины не выводятся, мышцы получают дополнительную усталость, спазмируют
* Интенсивная мозговая активноть в слабопроветриваемых помещениях. Выше описаны последствия
* Задержка дыхания при концентрации. Это неконтроллируемый процесс, но его надо стараться не допускать
* Всматривание в что-то на экране. Это тоже спонтанных процесс. Если вы работаете с мелкими деталями, то лучше использовать максимальное приближение, чтобы не было желания перефокусироваться на мелочи, ведь расстояние до монитора не изменится, но глаз будет лишний раз вхолостую работать
* Ограничения в еде. Недостаток витаминов и минеральных веществ приводит к плачевным последствиям

Исправляйте причины, не симптомы.

1. Большой ЖК монитор с высокой частотой и контрастностью.
2. Белые темы (черные символы на мягком светлом фоне) днём.
3. Черные темы (светлые символы на тёмно синем фоне) ночью.
4. Периодические перерывы (примерно раз в 30 мин.).

20 20 20… каждые 20 минут, 20 секунд смотрю на расстоянии более 20 метров.

Используем C#, DataObjects.Net
ORM с методолгией CodeFirst значительно упрощает поддержку БД.
Примеры:
1. Удалили поле из таблицы — нам нужно каким-то хитрым образом проверить все запросы которые могут использовать это поле. В случае работы через ORM мы уже на этапе компиляции не сможем написать неправильный запрос.
2. Переименование поля — при ORM можем пользоваться всеми возможностями таких штук как Resharper, и автоматом переименовывать там где надо.
3. Не самая высокая оптимальность запросов через ORM частично компенсируется возможностью кэширования на appserv, а так же возможностью выполнения части запросов на appserv (с учетом легкой масштабируемости последнего)
4. В качестве доп. бонуса, хотя и не особо используемого нами — получаем переносимость на другие БД

написал статью тут — habrahabr.ru/blogs/programming/123293/

Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

Чтобы писать запросы на своём языке программирования, а не интегрировать в исходник ещё один язык.

> Так в чём профит?

Вы пробовали поддерживать проект, который поддерживает 5-6 СУБД?

некий интерфейс для работы с данными, которые не важно в каком виде и где находятся… в коде очень удобно работать с объектом, который представляет некоторый набор данных…

interface IMyInterface1
{
    string Prop1 {get;set;}
    string Prop2 {get;set;}
}

interface IMyInterface2
{
    string Prop1 {get;set;}
    string Prop3 {get;set;}
}

class MyClass : IMyInterface1, IMyInterface2
{
    string Prop1 {get; set } // Общее свойство
    string Prop2 {get; set }
    string Prop3 {get; set }
}

Вы такую ситуацию имеете в виду? Если да, то так можно делать. Свойство Prop1 будет реализовывать сразу 2 интерфейса.

Немного офтоп, но всё же.
Для избежания шума от рабочего компа (не сервера) я приминил радекальный способ.
Отверстие в стене и комп жужжит на кухне а я сижу в тихой комнате.
Стандартной длинны проводов хватило. Тишина 100%-ая.