Gå til innhold

Bro2

Medlemmer
  • Innlegg

    536
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av Bro2

  1. Du har avfeid ganske mange argumenter, bl.a. navnekonvensjoner, bruk av norske metodenavn, null som returverdi, strukturen av grensesnittet, uten å komme med noen særlig begrynnelse annet enn
    men å klage på misbruk av null-pekere blir for dumt.

    Feilen ved oppgaven er ikke en kjempebrøler et sted, men at det er ganske mange småting som gjør den ganske rotete. Og når du avfeier feilene blir det heller vanskelig å argumentere...

    Det du skriver her er ikke riktig, for jeg har ikke avfeid argumentene.

    Jeg avfeier derimot konklusjonen om at oppgaven er idiotisk på bakgrunn av argumentene som er presentert.

    For å kunne konkludere med at oppgaven er idiotisk må man klare å komme opp med mer enn småplukk.

     

    Oppgaven er ikke idiotisk fordi grensesnittet ikke følger navnkonvensjonene til punkt og prikke.

    Den er heller ikke idiotisk fordi det brukes norsk.

    Jeg har forklart at null brukes som returverdi av en enkel grunn, nemlig for å unngå unntak (exceptions).

    Greit nok at det kunne vært en tom streng istedenfor, men jeg kan ikke se at løsningen blir så utrolig mye bedre.

     

    Jeg ser heller ikke hvorfor oppgaven er idiotisk, men den har klart forbedringspotensiale.

    Bedre bruk av norske navn (giPerson?!, hva med hentPerson?. nyFarEllerMor? nyForelder).

    Følge Suns navnekonvensjoner... (Ja, så lenge java brukes som verktøy for å undervise OO, bør man følge javas konvensjoner og hvis man ikke gjør det, forklare hvorfor. Det vil bedre forståelsen blant studentene på hvordan man skriver pen kode)

    Fjern null-pekere, en ekstra compareTo er penere.

    Kanskje la LeggTilPerson ta en string og returnere et nytt personobjekt med navnet satt? Så alle metodene i grensesnittet tar strenger som parametere?

    Man kan godt gjøre forandringer på norsken hvis man ønsker det, men at «giPerson» er så forferdelig klarer jeg rett og slett ikke å se.

    Ellers har jeg ikke sagt meg uenig i noen av punktene, så kritikken din slår feil.

     

    Jeg er selv enig i at oppgaven har forbedringspotensiale, noe jeg har skrevet tidligere.

     

    Poenget mitt har aldri vært at oppgaven ikke kan forbedres.

    Poenget mitt er, som jeg har skrevet gang på gang, at argumentene som presenteres, som hovedsakelig går på forbedringer på grensesnittet, ikke er tilstrekkelig for å konkludere med at oppgaven er idiotisk.

  2. Det blir for tåpelig å gjemme seg bak «du er så emosjonelt knyttet til oppgaven».

    Jeg irriterer meg over utsagn som mangler en begrunnelse.

     

    Mitt poeng er ikke at oppgaven er fantastisk bra. Poenget mitt er at han ennå ikke begrunnet sin påstander som rettferdiggjør hans utsagn om at oppgaven er idiotisk.

     

    Eller...synes du det?

  3. Jeg ser poenget ditt, men jeg vil si at de lærer objektorientering like bra selv om modell-klassen kan tenkes å representere en database.

    I bunn og grunn er det vel en vurderingssak, så det kunne så absolutt vært gjort med objekter istedenfor.

     

    Jeg etterlyser fortsatt en seriøs begrunnelse fra pgdx, men som jeg nevnte tidligere ser det ut til han han tok seg vann over hodet ved den uttalelsen om at oppgaven er idiotisk.

  4. Bro2:
    Grunnen til at strenger faktisk er legitimt her er at modellklassen kan representere en database der dataene lagres som strenger og ikke objekter.

    Dette er en vurderingssak, som ikke har noe fasitsvar synes jeg.

     

    Har det siste året brukt en object relation mapper (ORM) som følger EJB3 standarden (enterprise java beans 3)* og der hadde det vært helt naturlig å mappe en klasse som f.eks Person fra oppgaven til en databasetabell. (Riktignok ikke med navn som en naturlig nøkkel og noen slike småendringer). Ser derfor ikke noen grunn til at du nevner at hvis man jobber med databaser så jobber man med strenger, ikke med objekter.

    Nå har ikke jeg skrevet at man ikke kan jobbe med databaser og objekter.

    Jeg skrev at man kan tenkte på det som en database der man jobber med strenger.

     

    Du kan riktignok jobbe med deler av flere tabeller og da blir det mer som strenger, ikke objekter, men det gjøres gjerne kun ved f.eks rapportering eller andre oppgaver hvor man skal håndtere store mengder data. Logikkmessig kan det gjerne håndteres med objekter.

     

    Har hjulpet en kompis med oppgaven og syntes den var rimelig bra, men irriterer meg over manglende bruk av java code convention**. Jeg ser ingen god grunn til å ikke følge denne.

     

    * http://www.hibernate.org/351.html

    ** http://java.sun.com/docs/codeconv/

    Jeg kan ikke se de store feilene annet en grensesnittet.

    Hva annet tenker du på?

  5. Emnetittelen i denne tråden er lite beskrivende for trådens innhold og det er derfor ingen god emnetittel. Jo bedre og mer beskrivende emnetittelen er, jo lettere er det for andre å skjønne trådens innhold og det vil være lettere å treffe den riktige forumbrukeren med det rette svaret. Ber deg derfor om å endre emnetittel slik at du unngår at en moderator stenger tråden. Vennligst forsøk å ha dette i tankene neste gang du starter en tråd, og orienter deg om hva vår nettikette sier om dårlig bruk av emnetitler.

     

    Bruk p_edit.gif-knappen i første post for å endre emnetittelen.

     

    (Dette innlegget vil bli fjernet ved endring av emnetittel. Ikke kommenter dette innlegget, men p_report.gif gjerne dette innlegget når tittelen er endret, så vil det bli fjernet..)

     

    Jeg er enig i at tittelen ikke er spesielt utfyllende eller gir godt innblikk i hva dette handler om, men det er lite jeg kan gjøre med dette.

    Kan ikke du endre den til noe sånt som "Problem med stebarn i en oppgave. Kvaliteten på oppgaven?"

  6. Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

    Det er kanskje ikke noe du er vant med...?

    Au da, min flåsete kommentar var helt unødvendig. Beklager :)

     

    Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

    Hvorfor har det da ennå ikke kommet seriøse argumenter?

    Ok, så er navnekonvensjoner et teit argument. Å lære seg å skrive kode som andre kan lese kan man tidsnok gjøre senere. Det at koden blir MER forvirrende for en som kan Java driter vi selvsagt i. ("giPerson()", "Modell_grensesnitt" -- hallo?)

    Hva er problemet med metodenavnet "giPerson"?

     

    Men: hvis man først skal programmere objekt-orientert, hvorfor bruker man ikke da OBJEKTER?

    public String registrerEkteskap(String mann, String kvinne);

    Man har jo allerede Person-klassen, hvorfor ikke bruke den? Dette er gjennomgående i ca HALVPARTEN av oppgaven, man er ikke konsekvent.

    Her er jeg tildels enig.

    leggTilPerson(Person nyPerson); burde tatt imot tre strenger.

    Navn, mor og far.

     

    Grunnen til at strenger faktisk er legitimt her er at modellklassen kan representere en database der dataene lagres som strenger og ikke objekter.

    Dette er en vurderingssak, som ikke har noe fasitsvar synes jeg.

     

    Modell_grensesnitt ser ut som et grensesnitt for en slags collection av Person-objekter, et folkeregister. Men hvorfor har folkeregisteret metoder som fint kan og bør tilhøre Person-objekter, slik som finnSteSosken og finnHalvSosken? I tillegg synes jeg inn/ut bør skilles fra domene-spesifikk kode. "Bør" er for svakt. Skal vi leke MVC så SKAL det.

    Person-objektenes ansvar er å representere en person og dens forhold til andre personobjekter.

    Databasen vil ha ansvaret for å skaffe dataene som kontrollen har behov for.

     

    MVC er et "architectural pattern" og går kort og godt ut på å gi en pekepinn på hvordan kontrolldelen og datadelen og "view"-delen av et program skal gøres adskilt.

     

    Person-klassen brukes kun som en praktisk lagring av dataene som programmet kan bruke.

    Den er ikke en direkte del av MVC i denne oppgaven.

     

    Jeg har forstått at man ikke skal lære bort exceptions så tidlig, så derfor skal jeg unngå å kommentere at feilhåndteringen ser ut å være skrevet av en gammel C-programmerer.

    Ja, jeg er enig i dette, men som du poengterer ganske riktig så skal ikke Exceptions være en del av denne oppgaven.

     

    Som andre har påpekt, du ser ut til å ta det veldig personlig at oppgaven ikke nødvendigvis er den beste. Jeg har selv gått på UiO og tro meg; oppgavene var langt dårligere da (det var andre året man underviste i Java, ting var ikke helt på plass...). Men jeg ble ikke lei meg om noen bemerket det. Det bør ikke du bli heller.

    Ja, da jeg gjorde oppgaven var den sikkert omtrent som da du gjorde den, og ikke spesielt ryddig selv om målet med oppgaven fortsatt er det samme.

     

    Jeg siterer det jeg skrev tidligere:

     

    Det har nok mer med at jeg blir utrolig irritert over deres oppførsel.

    Først slenge ut ubegrunnede påstander, og deretter unngå å begrunne dem på en seriøs måte.

    Navnkonvensjoner og lagring av data som stringer er på ingen måte grunn nok til å konkludere med at oppgaven er idiotisk.

    En ting som er verre enn å ta ting personlig er å ikke klare å begrunne sine påstander.

    På et forum er det faktisk noe man pleier å gjøre.

    Jeg kan godt være enig i at oppgaven er et forbedringspotensiale, men jeg skjønner fortsatt ikke at det er mulig å konkludere med at denne oppgaven er idiotisk på bakgrunn av punktene som poengteres.

     

    Takk for et seriøst svar, noe jeg observerer at pgdx fortsatt unngår å komme med.

  7. Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?
    Nja, ikke alltid det er verdt det. Man ser an sitt publikum. Enkelte er ikke mottakelig for konstruktiv kritikk.

    Nei det er riktig, spesielt ikke kritikk som er håpløs flisespikkeri. Jeg forventet faktisk noe seriøst fra dere.

     

    Det er kanskje ikke noe du er vant med...?
    Nice

     

    Synes du virkelig det er rart at jeg setter spørsmålstegn ved dette?

    Er det så fremmed å skulle begrunne sine påstander?

     

    Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

    Hvorfor har det da ennå ikke kommet seriøse argumenter?

    Fantastisk dårlig, ja ... Jeg tror vi har påpekt navnekonvensjoner og å bruke strenger for å representere en form for data. Du feide bort de og vi gav oss.

    Ja, og jeg finner det fullstendig tåpelig å konkludere med at oppgaven er idiotisk på grunn av dette.

    Navnkonvensjoner har lite med oppgavens evne til å lære studentene programmering og objektorientering, noe som faktisk er målet med dette kurset.

    Å lagre data som stringer er faktisk helt legitimt. Det kan ses på som å representere en database.

     

    Fra tidligere poster ser det i alle fall ikke ut til at det mangler engasjement....men men...hjem deg bak «nei, nå gidder jeg visst ikke» du.
    Nice. Du tar visst denne kritikken veldig personlig. Det er nok ikke det lureste man kan gjøre på et forum.

    Det har nok mer med at jeg blir utrolig irritert over deres oppførsel.

    Først slenge ut ubegrunnede påstander, og deretter unngå å begrunne dem på en seriøs måte.

    Navnkonvensjoner og lagring av data som stringer er på ingen måte grunn nok til å konkludere med at oppgaven er idiotisk.

    En ting som er verre enn å ta ting personlig er å ikke klare å begrunne sine påstander.

    På et forum er det faktisk noe man pleier å gjøre.

     

    Jeg skjønner at det er håpløst å forvente noe mer fra din kant i alle fall.

    Det virker for meg som du tok deg vann over hode da du slang ut en bemerkning du ikke klarer å begrunne.

    Ingenting er så lett som å kritisere, men å faktisk gi en god begrunnelse og forslag til hvordang gjøre forbedringer har du vel merket ikke er så enkelt.

  8. Det må være fordi vi har snudd på flisa og funnet ut at denne oppgaven representerer det ypperste av objektorientering og Java-programmering.

     

    Eller var det fordi man ikke gadd? :)

    Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

    Det er kanskje ikke noe du er vant med...?

     

    Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

    Hvorfor har det da ennå ikke kommet seriøse argumenter?

     

    Fra tidligere poster ser det i alle fall ikke ut til at det mangler engasjement....men men...hjem deg bak «nei, nå gidder jeg visst ikke» du.

  9. Hei

     

    Hvis man ikke skal koble til en maskin til nettverket, hva koster det å komme inn?

    Hvis man tar med en bærbar og ønsker å koble den til det trådløse nettet, men fortsatt uten en fast plass, hvor mye koster det?

     

    Er det parkeringsplass utenfor hvor det går an å parkere? Hva koster det?

     

    Takk for svar.

  10. Morn

     

    Tenker på en Panasonic plasma-TV på 42".

     

    Det var en som nevnte at HD-Ready er en fordel når en skal se på vanlig TV f.eks. kabel fra Get, rett og slett fordi kvaliteten på bildet blir bedre enn med Full-HD.

    Har ingen planer om å kjøpe Blu-ray, men vil det være en fordel med Full-HD når det nye digitale bakkenettet tas i bruk?

     

    Skal koble til PC og spille DVD og andre typer formater.

     

    Takker for svar.

  11. Jeg hørte en historie da jeg var i militæret, der en løytnant skulle dra bort, og skulle gjerne hatt tillgang til internett der han skulle. Dette skjedde for en del år siden.

    Hans overordnede som mest sannynlig var en høyererangs gamling foreslo at han kunne lagre internett på en diskett.

    Løytnanten måtte forklare at dette ikke er mulig fordi internett tar for mye plass, hvor hans overordnede svarer noe sånt som dette:

    "Greit, så bruk en CD da!"

     

    :!: :D :D

     

    Det er liten tvil om at det finnes en del fjerne folk i millitæret!

  12. En film uten særlig mål og mening, kanskje var det poenget, men filmen gir meg ikke noe mer av denn grunn. Føler jeg sitter med lite igjen etter å ha sett filmen. I dens forsvar skal det sies at den er overraskende lite kjdelig underveis tatt i betraktningen mangelen på mål og mening. Jeg klarte rett og slett ikke å bry meg nok om de dysfunksjonelle menneskenes skjebne.

     

    AtW

    Har du sett Happiness? Om sammenligning med Happiness er rettmessig så skal jeg få sett Lønsj. Mål og mening trenger ikke en film, det kan godt være masse scener som belyser mennesker og fremdeles være kjempebra. Men som sagt, om bare en person til kan si noe om sammenligningen med Happiness så hadde det vært fint :)

    Aldels uenig. Selvfølgelig trenger en film mål og mening.

    Det betyr ikke at alt skal være tydelig, skrevet med store bokstaver, men denne filmen var ikke særlig interessant spør du meg.

    Jeg kom ut fra kinoen og «hørte» meg selv si; «whatever».

     

    Å prøve å sammenligne denne filmen med filmer som Magnolia blir hinsides.

  13. Jaja, jeg fikk godkjent oppgaven til tross for noen bugs (forventet det egentlig, bugsa altså).

    Gratulerer! Bra jobbet!

     

    Det er ikke jeg som har laget grensesnittet, men forelesere/gruppelærere. Vi ble bedt om å bruke dette. Klart har det en pedagogisk effekt når det er _først_ gang vi bruker MVC og grensesnitt. Ha litt forståelse når de aller fleste på kurset ikke har programmert noe annet enn INF1000, dvs et halvt års kjennskap til java.

    Erfaringen viser at denne oppgaven er meget effektiv til å lære hvordan MVC kan brukes (i alle fall hva som er tanken bak MVC) i forhold til tidligere år.

     

    Vi/jeg har også blitt bedt om å bruke norsk variabel navn. Hvorfor vet jeg nok ikke, men jeg gjør det jeg blir bedt om. Har ikke noe problem med å lage engelske variabelnavn. Tragisk å klage på dette hvertfall...

    Jeg tror dette kommer an på hver gruppelærer.

    En grunn kan være at det er enklest hvis alle gjøre det samme.

     

    Jeg kan godt si meg enig i at man kan bruke engelske variabelnavn, men at dette skal være et stort problem slik flere her påstår kan jeg ikke skjønne.

    Det er tross alt stor forskjell på en obligatorisk oppgave og en oppgave der internasjonale programmerere skal samarbeide.

     

    Håper du er i gang med Oblig 2.

    Det er litt å jobbe med der også!

  14. Jeg synes nesten synd på deg...

    Nuvel, det skal du få slippe.

     

    Men jeg må si, jeg tok en nærmere titt på grensesnittet man skal implementere i denne oppgaven. Det var såpass rotete og lite konvensjonelt at det ser ut til å være laget av en førsteårs-student og ikke en foreleser. Noe av poenget er jo å lære hvordan skrive god kode, ikke hvordan sause i hop alt og allverdens i Modell_grensesnitt. Og hvis man ønsker å lære bort objekt-orientering så er ikke dette grensesnittet et særlig godt eksempel.

    Hva er rotete? Hva mener du med «sause i hop alt og allverdens i Modell_grensesnitt».

    Enda en påstand uten substans? Begrunnelser pleier å være er fordel.

  15. Jeg anså meg stort sett som ferdig med denne diskusjonen, men siden du ikke er fornøyd ...

     

    Konvensjoner er svært viktig når man programmerer. Jeg skal ikke anta mye om deg, men det virker nesten som om du enten har et personlig forhold til denne oppgaven (laget den, eller på en annen måte tilknyttet dette kullet eller UiO) eller at du bare ikke har programmert særlig mye.

    Helt riktig, jeg er tilknyttet dette kullet. Hva så?

     

    	/**
     * Registrerer en ny person i personregisteret.
     *
     * @param	 nyPerson   den nye personen som skal legges inn i personregisteret 
     * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
     */
    public String leggTilPerson(Person nyPerson);

    null skal faktisk returneres dersom ingen feil oppstår. Vel ... hva skal man si? Ingen steder i Collections returneres null ved suksess. Jeg forstår at studentene ikke kan exceptions, men å returnere null ved suksess er bare uintuitivt og misbruk av nullpekere. Det samme gjelder for mange andre metoder i grensesnittet.

    Vel, enig i at man f.eks. kunne returnert en tom streng, men å klage på misbruk av null-pekere blir for dumt.

    Det er klart og tydelig definert hvordan metodene skal fungere, og så fryktelig vrient er det ikke.

    Og ja, det er nok for å unngå exceptions. Visse justeringer er man nødt til å gjøre.

     

    	/**
     * Registrer en ny far eller ny mor for en person.
     *
     * @param	 person		 navn på person som får registrert ny far eller mor
     * @param	 nyFarEllerMor  navn på den nye faren eller moren
     * @param	 mor			angir om det er en ny far eller ny mor som skal registreres
     * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
     */
    public String nyFarEllerMor(String person, String nyFarEllerMor, boolean mor);

    Skal strengen person få en ny far- eller mor-streng? Tja ... ikke overbevisende, og ihvertfall ikke tilknyttet virkeligheten på noe som helst plan.

    Ikke overbevisende? Hvis en person har registrert feil mor eller far skal dette kunne endres. Hva er problemet med det?

     

    	/**
     * Finner helsøsken til en person. 
     *
     * @param	 navn		navn på person man skal finne helsøsken til
     * @return	helsøsken i et array. Hvis ingen helsøsken ble funnet returneres null
     */
    public Person [] finnHelSosken(String navn);

    Jeg ser jo her til min overraskelse at man skal returnere Person-objekter og ikke strenger, det er positivt. Hvorfor da må inputen være String navn og ikke Person person? Det samme gjelder alle tilsvarende metoder inkl. public boolean erSoskenbarn(String denEne, String denAndre);

    Overaskende at Person-objekter returneres? Hvorfor? Hva er poenget ditt?

     

    Når man ber om navn fra brukeren så leser man det inn fra tastaturet i form av tekst, representert i Java ved klassen String, ikke klassen Person.

    Modellen (f.eks. database) har lagret dataene om hver person. Ber man om informasjon om en person fra en database lager man en query (altså en string), og returnerer så informasjonen i et passende objekt (Person). Alt som trengs er en string. Hvorfor man må sende med Person-objekter skjønner jeg ikke.

     

    Jeg skjønner hvis du forsvarer oppgaven fordi den (liksom) skal være mer pedagogisk enn andre, men det er mye rart som må virke forvirrende for nye Java-ere. Du kan få komme med svar her hvis du vil, men hvis ikke du har noen direkte spørsmål, kommer jeg til å si meg ferdig med denne diskusjonen.

    Forklar gjerne hva som «liksom» er problemet annet enn «uff, grensesnittet følger ikke navnkonvensjonen» og «uff, misbruker null-pekere».

    Hva er det som er så forvirrende? Hva ville du gjort anderledes?

     

    Beklager, men «eller at du bare ikke har programmert særlig mye» er bare stusselig.

     

    Du får si deg så ferdig du bare vil. Det er du som mangler gode argumenter for dine påstander.

    Hvorfor er denne oppgaven idiotisk?

×
×
  • Opprett ny...