Дмитрий: Как раз и имел в виду, что периодические просматриваешь раздел куда отвечал)) Тем более, что ты вроде как довольно активно стараешься тут людям отвечать и значит ответов в списке не мало уже накопилось.
Дмитрий: О, ты мониторишь старые вопросы ?) Нет, к сожалению еще не там, пока работаю над самоорганизацией и дисциплиной. Переехал все-таки в Спб, а потом через какое-то время после ИС что называется расслабился. Сейчас в голове постоянно крутится другая проблема - в каком направлении развиваться и не знаю чего хочу на самом деле) А расфокусированность не дает фактически развиваться ни в чем нормально.
При чем это касается не только области программирования, но и есть мысли о том, что возможно управление проектами было бы мне ближе. Книги успевают раза в два быстрее накапливаться, чем я успеваю их читать. Сегодня как раза буду пытаться все-таки сформулировать уже конкретные цели на этот год.
P.s. я тогда не написал в личку, банально потому что на хабре у меня р/о акк)
@EvilsInterrupt Ну женщины вообще порой непредсказуемы) Сейчас в последний день вылета из Москвы обратно состоится еще 2й раунд собеседования в одну компанию. Мне поэтому интересно на какую зп имеет смысл переезда сейчас (при условии снимать однушку, один, не питаться дошираком). А то я сказал минимум 60к, вот думаю насколько это актуально сейчас вообще в москве.
@EvilsInterrupt Ну когда уже опыта наберешься - часто так и бывает, что люди уходят в более мелкие компании, где твое присутствие и твоя работа "ощущается". Это хорошо, что удалось найти мотивирующую работу :)
У меня же сейчас, на пороге принятия решения, намного больше сомнений возникает. С одной стороны - хочется профессионального роста, развития, работы над интересными проектами. С другой стороны - там никого вообще нет, все родственники остаются за много тысяч километров (перелеты будут весьма редкие). Будешь болеть - никого нет, и т.п. Много вопросов о том с чего начать, как найти нормально жилье, да даже придется учиться готовить самому. Благо хоть вопрос климата не так остро стоит, как для других - у нас тоже весьма печальный. Единственное - летом, на выходные могу спокойно на море съездить (минут 20). Вот сижу теперь смотрю квартиры в Питере и думаю, что же делать)
@EvilsInterrupt Почти) сначала приехал в Москву, посмотрел город в целом (без собеседований), сейчас с понедельника в Питере с культурным визитом, но тут есть еще и вполне конкретное интересное предложение о работе. Поэтому можно сказать сейчас его в первую очередь и рассматриваю. Завтра ночной поезд обратно в Москву и там пару собеседований запланировал, но в целом ничего интересного не было.
@kachailov Первое, что бросилось в глаза - в цикле While условие, сравнивать элементы болтов друг с другом нельзя. Переписать условие так попробуйте while (val2 < newArrayOfBolts[j]). Иначе получается, после первой перестановки сравнение уже не с тем значением идет. Проверьте это условие. Если нет, то по приезду домой, гляну более внимательно.
@kachailov Мне кажется вы уже пошли не самым лучшим путем. У вас уже, только для того, чтобы сформировать эти идентичные массивы - квадратичная сложность. А теперь еще надо отсортировать эти массивы. По-моей идее вместо, того чтобы искать пары, вы сразу после прохода получаете число - на какую позицию поставить этот элемент. Если сортировать в лоб, то вы еще один квадратичный алгоритм напишите.
На C# сортировку вставками (я так понял, сложность вас не особо волнует) сделал бы так для массивов A и B (не тестировал, писал на скорую руку, но вроде так):
for (int i =1; i < A.Length; i++)
{
int val1 = A[i];
int val2 = B[i];
int j = i -1;
@borgez Даже то о чем я писал - это так скажем для общего понимания происходящего. На самом деле проблема в вашей архитектуре, явно не так решаете проблему, либо не правильно формируете свои вопросы/ задачу.
C# - строго типизированный язык и это одно из его преимуществ - безопасность типов. Это означает, что на момент компиляции практически никаких неопределенностей быть не должно. Вы же пытаетесь их внести, как мне показалось. Множественное наследование поэтому и не используется, потом может вызывать неопределенности и проблемы с выполнением.
Я вам настоятельно рекомендую почитать основы по языку, потому что в том виде в котором вы сформулировали вопрос: "как написать конструктор\ класс чтобы его элементы он ссылались на родительский класс", ответ будет таким: это поведение по-умолчанию, когда есть публичное/защищенное свойство у родителя и это свойство передается наследнику. То есть наследник спокойно может с ним обращаться, как со своим. Проблема начинается в том месте, где вы пытаетесь в дочернем классе объявить Новое свойство (public dvsDizel dvs {get;set;}) с конкретным типом двигателя. Уберите его и у вас останется одно свойство двигателя от родителя.
Этот код создает 1 экземпляр объекта и присваивает его обоим свойствам. То есть оба свойства ссылаются на один и тот же объект.
Другой вариант, это в описании дочернего свойства dvs описать get { return (dvsDizel)base.dvs; } и set { base.dvs = value; } То есть получается второе свойство в дочернем классе - это всего лишь методы-оболочки для работы с родительским свойством.
autoA() : base() - означает, что при вызове конструктора для объекта типа AutoA, надо выполнить сначала действия описанные в конструкторе базового класса, то есть конструктор public AutoCommon(), а потом уже действия описанные в конструкторе дочернего класса autoA(). Угадаете какие действия в вашем случае там описаны в родительском классе ?) Правильно, никаких. То есть даже если вы уберите эту приписку : base(), ничего не изменится.
@rumkin Со стороны потребителя в принципе все верно, нужно стремиться минимизировать потери, спору нет. Особенно если речь про значительную сумму речь идет, хотя как я понял это не тот случай.
Но с другой стороны, если вы потеряли половину значительной суммы не получив ничего абсолютно, кроме разочарования, разве ваше мнение о компании или ее продукте улучшится ? Поэтому с точки зрения бизнеса терять деньги, ради фактически такого же в итоге нелояльного клиента - занятие не очень осмысленное. Тем более, что ПО это такой продукт, который не требует расходов на выпуск его экземпляра, тиражируй сколько угодно и ты ни рубля не теряешь. Поэтому тут разговоры о затратах времени кого-то из сотрудников, скорее как оправдание, чтобы вроде и деньги не возвращать, и вроде как попытаться сильно не доводить до откровенного конфликта.
Я против такой именно политики "оправданий", я за ответственность в бизнесе. Лажанул? Расплатись. Считаешь себя правым - забей на нытье и жалобы, время и клиенты рассудят. Но опять же, нужно гибко подходить, потому что ситуации и обстоятельства могут быть разные.
Если же вам вернут полную сумму, то вы хотя бы понимаете, что ничего не потеряли, кроме времени работая с этой компанией и возможно человек по-рекомендует продукт попробовать кому-то еще, а возможно и сам в последующем что-нибудь купит.
@rumkin Утрировать это конечно классно, но вы как клиент просили когда-нибудь "ну верните мне хоть что-нибудь?". Такой вариант работает, когда заранее установлены штрафы, например за сдачу билета за 24часа до отлета, за 3 часа и т.п. То есть четкая система возврата и система соответствующих штрафов, о которых пользователь знает заранее.
А теперь с другой стороны, вам продукт абсолютно никак не помог, полное разочарование. Вы просите сделать возврат. И тут вам продавец начинает ссылаться, что ну выыы же понимааааете, вернуть вам деньги это доолгая и сложная процедура для нашей бухгалтерии, а их время надо оплачивать. Мне как клиенту вообще плевать на на бухгалтерию и как они работают, медленно или нет. А еще вы же обращались в тех поддержку, просили подсказать можно ли вообще что-то делать в нашем ПО, а это тоже стоит денюшек. А еще с вами менеджер работал, ему тоже надо это время компенсировать. Даже если клиенту вернут часть денег в таком случае, да с одной стороны хоть что-то в карман вернулось (хотя судя по комментам ниже это будут копейки уже), а с другой - принципиально лучше от такого шага репутация уже не станет.
С другой стороны если вы коротко и ясно дали свою позицию - ПО возврату не подлежит по причинам 1, 2, 3 - по-крайней мере вы имеете четкую позицию в вопросе и не пытаетесь "оставить себе хоть еще пару рубликов за что-то".
Другой вопрос, что ситуация не до конца ясна, и по некоторым комментариям появилась мысль, что может клиент просил доработать ПО? Если были индивидуальные доработки, то это другой вопрос и такие моменты действительно должны оплачиваться.
Факторов много на самом деле, поэтому надо быть гибким. В первую очередь надо понять почему появилась необходимость возврата.
@severodvinsk1987 Если причина баги, сообщите клиенту когда примерно выйдет патч с их исправлениями. Можно даже предложить побыть немного тестером (знаю такие случаи по положительным рассказам о компаниях).
Даже в шторм действие, которое в большинстве случаев правильное, по набору определенных факторов может оказаться не правильным. Например, насколько мне известно, правильным в шторм считается не подставлять бока под волны, чтобы уменьшить вероятность переворота судна. Но были случаи, когда из-за жесткого перегруза и возможно не совсем верной конструкции, судно на волне разламывало на 2 половины.
Я это к тому, что вы лучше знаете обстоятельства, а как мы можем давать советы, когда не ясна вообще история ваших взаимоотношений и характер проблемы. Вы нам не сообщили набор исчерпывающих факторов, а значит любая рекомендация может оказаться в лучше случае бесполезной, а в худшем наоборот вредной.
Если мобилки, то тут либо подсесть на Xamarin (вот только это как мне кажется довольно опасная игла), если есть такая возможность, либо ios/android разработка. При всем при этом, списывать со счетов windows phone я б тоже не стал. Да, они упустили момент, да "перезагрузка" вышла не очень, но они всячески стимулируют разработку, продвигают, и бросать это направление вряд ли будут. Поэтому вполне вероятно, что какие-то ошибки будут исправлены и аудитория будет понемногу расти, а значит есть шанс вставить свои 5 копеек в маркете.
С c-obj проблемней работу найти без опыта и наличия приложений в эппсторе, поэтому быстрого старта не получится. Тем более, что мобильные приложения тоже как минимум можно разделить на 2 очень разных сегмента: игры и программки. И надо выбирать что-то одно в начале :)
Предыстория такова, что исторически, за неимением в давние годы мака - выбор пал на C#, как на наиболее близкий потомок к С++. И поэтому он уже довольно глубоко впитался в мозг, объективно оценивать тяжело) Поэтому возможно лучшее знание языка, пока делает его для меня так сказать более приятным, чем тот же C-obj. Специально делаю такую оговорку, потому что пока не знаю, может и у C-obj есть много всяких интересных фишек, стараюсь искать какие-то аналогии, но например лямбда-выражений нет)
Я уже писал, что если выпадет возможность устроиться работать iOs jun. то скорее всего, сделаю выбор в пользу этого направления. Не скажу, что это очевидное лидерство, но с точки зрения интересности чуть-чуть перевешивает. При чем интересность заключается не только в самой платформе и языке, а скорее в мобильной разработке вообще. Потому что как мне кажется скоро все будет происходить с мобильным устройств, а сервера будут в роли сервисных служб. Но если нет, то на C# - это однозначно в сторону ASP MVC и WCF, либо xamarin и не скажу, что расстроюсь. Более того, это все равно остается пока приоритетом. iOs как раз больше из интереса изучаю по вечерам.
@Kokcuk Все не мог добраться ответить, но это уже сделал @RKupkenov . Выражения "хоть на 1/10" слишком уж отдают "приверженностью эппл". Я хоть и пользуюсь их продукцией и мне нравится, но не стоит сбрасывать со счетов других производителей и вариант от асус вполне достоин. И когда я выбирал между макпро ретиной, как вариант я рассматривал, как раз асус. А потом через полгода еще смотрел, появился еще вариант от асуса с той же ценой, но по тех характеристикам уже обгонял мой мак (мощнее видео, 2 ссд по 256 и хорошая комплектация). Так что выбирать есть из чего, особенно если знать свои потребности.
@nfuture Немного дополню, по-личному опыту, что просто учить, потому что требуют - низкоэффективное мероприятие. Мозг штука хитрая, и при большом объеме новом информации, укореняется в памяти только то, что ты понял как можно применять на практике и действительно применяешь.
Зачем покупать мак, если полностью снести ОС от Apple. Тем более, что другие производители, потихоньку приближаются к адекватным конфигурациям, когда и норм железо, и SSD диск.
Если потребность в чисто вин приложениях небольшая, то лучше виртуалка.
Если по сегментная, то лучше второй осью, переключился поработал с чем надо и все, для остального вернулся обратно.
Если больше вин нужен, то и смысла мак выбирать не вижу, кроме яблочка на крышке, но это уже, как мне кажется - изврат)
P.s. и при установке винды из под OS X делается это вообще в пару кликов, только образ надо ему подсунуть с ключиком, остальное он скачает и потом установит.
@EvilsInterrupt Пока нет, я же изначально на конец мая запланировал, поэтому пока идет так сказать этап моральной и материальной подготовки, пробиваю почву, в том числе и по работе.
