Gå til innhold

ProgrammeringsBaren! Småprat, om det du elsker!


Anbefalte innlegg

#1: I starten av programmet, hent alle URLs fra fil.

#2: Dytt alle linker inn i en liste.

#3: Alle linkene du finner per iterasjon dytter du bakerst i listen din.

#4: Maintain dictionary/set med alt du har besøkt.

#5: Det første du gjør når du popper en URL er å sjekke existence. Dersom den eksisterer - bare skip.

#6: Det andre du gjør er å dytte denne URLen inn i visited.

#7: ?????

#8: profit.

  • Liker 1
Lenke til kommentar
Videoannonse
Annonse

Takk for svar! Siden den skal kunne resume state om den blir avbrutt, bør jeg da jobbe utifra en liste med ubesøkte og besøkte, samt hele tiden skrive kopier av disse listene til filer for å ha progresjonen lagret i minnet? Slipper jo å skrive hele url'en, men ihvertfall hele tiden la filene på disk være lik listen jeg jobber fra?

Lenke til kommentar

Jeg ville periodevis serialsiert og skrevet visited og queue, ja. Om du skriver smart holder det å skrive differansen (hvertfall når det kommer til queue).

Et tips her kan være å bruke en buffer med uskrevne urls.

 

Hver gang du har besøkt en url, legg til i visited (dict/set). Legg samtidig til i en buffer (array) på, say, 128 plasser. Hver gang denne er full: skriv (append) denne listen til visited-filen din og tøm bufferen. Gjenta.

 

Dersom du får abort eller exception: ta tak i signalet og gjør en post process; dump alt du har i queue samt innholdet du har i visited-bufferen. På resume trenger du bare å lese visited-filen inn i visisted-set og queue-filen inn i queue og fortsette der du slapp. Parametriser gjerne buffersize for å kunne justere kostnad.

 

Var det forståelig?

 

edit: buffer-oppførsel kan fint tunes på mange måter - det er avhengig av ytelseskrav og slikt.

Endret av Lycantrophe
  • Liker 1
Lenke til kommentar
Gjest Slettet+9871234

Jeg gjorde en programmeringsoppgave for en jobbsøknad, og endte med å ikke få jobben uten videre forklaring på hva som var galt med koden min. Er nå interresert i å få litt tilbakemeldinger, finslipe koden (det var en webcrawler) og ha den som en del av porteføljen min - hvilke sider er best for å gjøre dette? reddit.com/r/programming ? Diskusjon.no? Stackoverflow?

 

Har du lest denne http://www.webbotsspidersscreenscrapers.com/ boken og lastet ned koden?

 

Her har du et løst skissert prosjekt til en søkemotor:

 

http://www.skupot.com/

 

Jfr også signaturlenken Big data.

Lenke til kommentar
Gjest Slettet+9871234

Den boken

  1. bruker cURL som er sikrere.
  2. beskriver hvordan man skal lage en etisk bot som for eksempel respekterer robots.txt
  3. bygger opp et bibliotek som forenkler burken av regulære uttrykk
  4. beskriver hvordan man skal maskere boten slik at den oppfører seg som et menneske.
  5. pluss mye mer.

Noen har åpenbart møtt http://www.crawlwall.com/

 

Dersom forutsetningen var å bruke Python og finne opp hjulet på nytt, beklager jeg utenomsnakket. Lykke til med prosjektet. Jeg håper at den dampmotoren du konstruerer er satt i skuta før seilskipet er i land.

Lenke til kommentar

Den må også kjøpes, som er unødvendig når han bruker prosjektet for å trene på programmering. Det å scrape har blitt gjort tusenvis av ganger før, det var aldri poenget. Leser du i det hele tatt postene du svarer på?

 

Curl kan brukes i python. Etikk var aldri poenget. Regex-biblioteker finnes, de var aldri poenget. Det var aldri poenget å programmere menneskelig oppførsel.

Lenke til kommentar
Gjest Slettet+9871234

Den må også kjøpes, som er unødvendig når han bruker prosjektet for å trene på programmering. Det å scrape har blitt gjort tusenvis av ganger før, det var aldri poenget. Leser du i det hele tatt postene du svarer på?

 

Prøv deg med et nettsøk på tittel + .pdf om du ikke nekter å bruke det GOOG finner for deg. Koden kan uansett lastes ned. Heleren er som kjent like god som stjeleren. Jeg kjøpte og leste første utgave for flere år siden og automatiserte testingen av lenker med den. Nå bruker jeg http://validator.w3.org/checklink selv om den jeg lagde hadde utvidet funksjonalitet.

 

Curl kan brukes i python. Etikk var aldri poenget. Regex-biblioteker finnes, de var aldri poenget. Det var aldri poenget å programmere menneskelig oppførsel.

 

Kan ikke du komme med nyheter?

 

Kan du følge denne http://www.haxx.se/ lenken til denne siden http://curl.haxx.se/libcurl/ finner du mer.

 

Fint at du hever kvaliteten på diskusjonen.

 

Beklager som sagt utenomsnakket.

Endret av Slettet+9871234
Lenke til kommentar

 

Curl kan brukes i python. Etikk var aldri poenget. Regex-biblioteker finnes, de var aldri poenget. Det var aldri poenget å programmere menneskelig oppførsel.

Kan ikke du komme med nyheter?

 

Virket nå som om det var nyheter for deg - hvorfor skulle du ellers presentert utsagnene?
Lenke til kommentar
Gjest Slettet+9871234

 

 

Curl kan brukes i python. Etikk var aldri poenget. Regex-biblioteker finnes, de var aldri poenget. Det var aldri poenget å programmere menneskelig oppførsel.

Kan ikke du komme med nyheter?

 

Virket nå som om det var nyheter for deg - hvorfor skulle du ellers presentert utsagnene?

 

 

Og hvorfor skal du trette de andre med ditt vås og din kverulering? Må du fortelle andre hva de skal gjøre?

 

Metadebattanten sanker fortsatt billige poeng.

 

 

Bare hyggelig.

 

Jeg ville fint hoppet over posten til kgun. Bare vås.

 

Du får skrike om du blir stående fast eller ønsker videre kritikk.

 

Ro deg heller ned her

 

https://forums.embarcadero.com/index.jspa

 

en stund, så lærer du deg virkelig programmering.

 

Nok utenomsnakk i tråden med tittelen:

 

ProgrammeringsBaren! Småprat, om det du elsker!

 

:roll: ??????

Endret av Slettet+9871234
Lenke til kommentar

Beautifulsoup eller en annen html-parser er veien. Regex er ikke helt greit fordi:

 

#1: regex er gjerne (linje i praksis)-basert og det er ingen krav om newline i HTML.

#2: HTML er ikke regulært. Moderne regex-enginer tar også ting som strengt tatt ikke er regices, men det er fortsatt et klønete tool.

#3: dem expressions.

 

Bruk en HTML-parser eller en lineær* scan. Det førstnevnte er enklest, men du kan vel i teorien misse noen tilfeller.

 

*Tokenize left-to-right. Hver gang du treffer en http://, les til du treffer en illegal character ELLER noe som kan være en del av noe annet enn url (i HTML er vel det <, altså tag). Begge er langt mer jobb enn det er verdt - det er bare å anta at alle linker er inne i <a>.

 

edit: i utgangspunktet skal du ikke være redd for 3rd party dependencies. Dette kommer fra en med absolutt aversjon for trivielle biblioteker. Spesielt noe som er såpass "agreed upon" som beautifulSoup er.

 

Regelen min er stort sett: er det pakket for debian er det ok å bruke. Uansett, det å parse HTML er ikke det faktiske problemet at hand, så kan du bruke et bibliotek for å slippe unna med noe så gjør du det.

Endret av Lycantrophe
  • Liker 2
Lenke til kommentar
Bør jeg bruke beautiful soup, regex eller en annen løsning til å hente ut linker fra html,

 

Du bør helt klart bruke en parser,Beautiful Soup eller lxml.

lxml bruker jeg en del pga Xpath og CSS-selector.

Beautiful Soup har også fått CSS-selector,noe den ikke hadde i tidligere versjoner.

 

Bruk av parser en en selvfølgelighet med HTML,men det utelukker ikke bruke av regex.

Både Beautiful Soup og lxml kan tolke regex uttrykk,eller mixe inn regex viss det er noe parser sliter med.

Endret av snippsat
Lenke til kommentar

Er det noen som synes det er greit å droppe system eller integrasjonstester?

 

Jeg er ofte borti at systemtester og integrasjonstester har en tendens til å feile sporadisk (feilaktig) og dersom de faktisk brekker tar det nesten alltid timesvis å finne ut av hva som faktisk er i veien. Dette sammen med at det fører til en mangedobling av tiden det tar før en faktisk kan deploye gjør at jeg funderer på om det faktisk ikke er verdt tiden en bruker på dem.

 

Ofte ser det ut til at dersom en i det hele tatt har systemtester finner folk det langt enklere å nesten bare skrive systemtester fremfor unit-tester.

 

Sånn jeg ser det så virker det til at poenget med systemtester blir å hindre at bugs kommer ut i produksjon, men når det først gjør det, tar det 10 eller 100 ganger lenger tid å rette buggen og legge ut en fiks ettersom det tar lenger tid å finne problemet, og lenger tid å produsere en ny build.

 

Noen andre erfaringer rundt dette?

Lenke til kommentar

Eg skylder meir på dårlege tester. Du skal alltid programmere for å handtere feil. Når feil skjer, så skal ein gi fyldig tilbakemelding som gir oversikt av kva som er galt eller kva som kan ha gått galt. Er ikkje dette på plass så er testen mangelfull...

 

Framtida er distribuerte tjenester, og då må ein ha integrasjonstester.

  • Liker 1
Lenke til kommentar

Eg skylder meir på dårlege tester. Du skal alltid programmere for å handtere feil. Når feil skjer, så skal ein gi fyldig tilbakemelding som gir oversikt av kva som er galt eller kva som kan ha gått galt. Er ikkje dette på plass så er testen mangelfull...

Integrasjonstester forteller forteller sjeldent hva som er galt. Det er en ti sider lang stack trace, og feilen er som regel en følgefeil av noe annet.

 

Framtida er distribuerte tjenester, og då må ein ha integrasjonstester.

Eller du kan skrive tester mot spesifikasjonen til tjenesten istedet for å sjekke om nettlinja di er oppe og at de ikke har nuket testdata.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...