Programowanie - temat ogólny

**zakius** · 09-06-2015 22:15

Roller, generalnie każde idę jb to po prostu bundle idei z rozszerzeniami

Rollercoster · 09-06-2015 22:22

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Roller, generalnie każde idę jb to po prostu bundle idei z rozszerzeniami

Yea, i to nie jest problem. Problemem byłoby to gdyby każde IDE było probione po łebkach i na 'jedno kopyto' byle było. A tak nie jest.

2cztery7 · 09-06-2015 22:28

jedyny minus ide od jb to 350 mb ramu zajęte zaraz po odpaleniu, po kilkudziesięciu minutach pracy lekkim chujem pół gigabajta
dla porównania vs zaraz po uruchomieniu i odpaleniu jednego projektu zajmuje ~130 mb

**zakius** · 09-06-2015 22:32

Od kiedy to vs nie zjada calydostepny*1.1?

2cztery7 · 09-06-2015 23:00

przynajmniej od 2013

Wielkie Zło · 10-06-2015 00:15

2cztery7 napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

jedyny minus ide od jb to 350 mb ramu zajęte zaraz po odpaleniu, po kilkudziesięciu minutach pracy lekkim chujem pół gigabajta
dla porównania vs zaraz po uruchomieniu i odpaleniu jednego projektu zajmuje ~130 mb

Ogromny problem w dzisiejszych czasach, gdzie 8GB RAMu to standard.

2cztery7 · 10-06-2015 01:00

taa, developetrzy mają w dupie optymalizacje, a potem robią gry wymagające 16 gb ramu i dwóch kart graficznych z najwyższej półki i chłodzenia ciekłym azotem xD

Wielkie Zło · 10-06-2015 01:06

2cztery7 napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

taa, developetrzy mają w dupie optymalizacje, a potem robią gry wymagające 16 gb ramu i dwóch kart graficznych z najwyższej półki i chłodzenia ciekłym azotem xD

Mają w dupie bo raz, że nie mają pojęcia o komputerach bo przecież studia nie są potrzebne, a dwa, biznes ciśnie i nie ma czasu na optymalizację bądź korzystanie z języka z ręcznie zarządzaną pamięcią. Realne życie to nie akademicka walka o każdy bajt pamięci.

Kusterek · 10-06-2015 09:06

Wielkie Zło napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Mają w dupie bo raz, że nie mają pojęcia o komputerach bo przecież studia nie są potrzebne, a dwa, biznes ciśnie i nie ma czasu na optymalizację bądź korzystanie z języka z ręcznie zarządzaną pamięcią. Realne życie to nie akademicka walka o każdy bajt pamięci.

Dobre gada, polać mu

**zakius** · 10-06-2015 09:41

Wielkie Zło napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Realne życie to nie akademicka walka o każdy bajt pamięci.

ale nie można przesadzać też w druga stronę, czyż nie?

konto usunięte · 10-06-2015 09:44

Wielkie Zło napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Mają w dupie bo raz, że nie mają pojęcia o komputerach bo przecież studia nie są potrzebne, a dwa, biznes ciśnie i nie ma czasu na optymalizację bądź korzystanie z języka z ręcznie zarządzaną pamięcią. Realne życie to nie akademicka walka o każdy bajt pamięci.

Odnośnie optymalizacji kodu, ostatnio czytając ksiazke A. Williams'a (C++ Concurrency in Action, polecam) podał on fajny przykład odnosnie aplikacji single i multithreaded. Kiedyś kiedy wszyskie (większość domowych komputerów) miała 1 rdzeń, programisci pisali aplikacje na 1 rdzen - i w miare czasu, jak producenci procesorów wprowadzali lepsze procesory, ich aplikacje samoczynnie stawały się szybsze. Sytuacja się zmieniła, gdy producenci procesorów zaczli wprowadzać procesory multirdzeniowe na dekstopowe PC - wtedy programisci musieli zmienić swoje aplikacji (w większości case je przepisać), żeby supportować tą większą moc obliczeniową. Oczywiście część programistów pojechała po bandzie, i przesiadła się na języki/technologie które robią to ^ za nich.

Z drugiej strony, stoi PM/PO ktory średnio dba o to czy Twoj kod jest schludny/szybki/whatever, dla niego ważniejsze są zrobione ficzerki ze sprinta - implikuje to też presję na programiscie.

Bazan · 10-06-2015 09:58

szulak napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Z drugiej strony, stoi PM/PO ktory średnio dba o to czy Twoj kod jest schludny/szybki/whatever, dla niego ważniejsze są zrobione ficzerki ze sprinta - implikuje to też presję na programiscie.

Z trzeciej strony, w myśl pojecia "Profesjonalista" jakim posluguje sie wujek Bob - programista ma uświadamiać swojego pracodawcę, że są rzeczy których nie można przyspieszyć kosztem jakości. Bo z każdą taką presją problemy się piętrzą, a ostatecznie to jest wina programistów że program działa gorzej niż mógłby. Ale standardowo wszystko kończy się na "To zależy..." :D A naprawianie "po" jest ZAWSZE drozsze niz "teraz".

**Deep** · 10-06-2015 10:08

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

ale nie można przesadzać też w druga stronę, czyż nie?

Moim zdaniem nie istnieje coś takiego jak "przesadzenie z optymalizacją". Jest kod mniej lub bardziej zoptymalizowany. Fakt, często im bardziej odptymalny tym mniej czytelny, ale... Od tego są komentarze ;)

**Haan** · 10-06-2015 10:13

Przy okazji rozmow o optymalizacji warto wspomniec o YAGNI

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%

konto usunięte · 10-06-2015 10:14

Bazan napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Z trzeciej strony, w myśl pojecia "Profesjonalista" jakim posluguje sie wujek Bob - programista ma uświadamiać swojego pracodawcę, że są rzeczy których nie można przyspieszyć kosztem jakości. Bo z każdą taką presją problemy się piętrzą, a ostatecznie to jest wina programistów że program działa gorzej niż mógłby. Ale standardowo wszystko kończy się na "To zależy..." :D A naprawianie "po" jest ZAWSZE drozsze niz "teraz".

Yeah, ale realia są troszkę inne. Jak masz grooming/planning, to oceniasz task na powiedzmy 3 dni. Po 3 dniach, okazuje się że było 10 problemów więcej do rozwiązania, więc sprint i demo jest zagrożone - więc się nadrabia.

Temat: Programowanie - temat ogólny

Narzędzia tematu

Oceń ten temat

Informacje o temacie

Użytkownicy przeglądający temat

Podobne tematy

Star Wars: The Old Republic - temat ogólny

League of Legends //dla potomnosci: League of Legends - temat ogolny.

Cities XL 2012 - temat ogólny

Dragon Ball Legend temat ogólny

Zakładki

Zakładki

Zasady postowania