| Parameter | Value |
|---|---|
| hashtag | #combine19 |
| start_day | 2019-12-09 |
| end_day | 2019-12-09 |
| timezone | Australia/Sydney |
| theme | theme_light |
| accent | #4a86e8 |
| accent2 | #A4C2F3 |
| kcore | 2 |
| topics_k | 6 |
| bigram_filter | 3 |
| fixed | TRUE |
| seed | 1 |
An analysis of tweets from the #combine19 hashtag for the COMBINE Symposium 2019.
A total of 251 tweets from 77 users were collected using the rtweet
R package.
Filtered for dates 2019-12-09 - 2019-12-09 in the Australia/Sydney timezone.
The “replies network”, composed from users who reply directly to one another, coloured by PageRank.
The “mentions network”, where users mention other users in their tweets. Filtered for a k-core of 2. Node colour and size adjusted according to PageRank score.
| screen_name | text | retweet_count |
|---|---|---|
| AliciaOshlack | Today I’m following #combine19. If you are a computational biology or bioinformatics student you should get involved in this. I’ve had 3 Combine presidents in my group! | 9 |
| lazappi |
Congratulations to @Katarina_Stuart, @LinYingxin and the rest of the committee for putting together #combine19! 🎉 If you want to be involved next year consider nominating to join the @combine_au committee https://t.co/Qtre7DF2k1. |
7 |
| combine_au | Our fabulous symposium organisers @Katarina_Stuart @LinYingxin kicking our day off! #combine19 https://t.co/ynboNgpTht | 5 |
| combine_au | @NhiHin use zebra fish to model familial Alzheimer’s disease and demonstrate the alteration in iron homeostasis by comparing differences in the transcriptome of iron response element gene sets. @combine_au #combine19 https://t.co/iy2OCf9ess | 5 |
| YiwenWang_Eva | Do you wanna to simulate more scenarios in gene family evolution? Then you cannot miss the talk of Qiuyi. He introduces a new model called IxDTL. Well done! Qiuyi! #COMBINE19 @QiuyiLi2 @MelbIntGen https://t.co/OK3AU73Z93 | 5 |
| JovMaksimovic | For everyone who will be attending the @abacbs post doc event at 6pm tonight in the beer garden at the Alfred Hotel (https://t.co/qzQ8iLSUtt) there will be a bar tab! Enjoy the 🍻 and say “Hi!” to Ignatius Pang who has kindly stepped in to host in my stead #combine19 #ABACBSGIW19 | 4 |
| AusBiocommons | We’re so pleased to be sponsoring and attending the @combine_au Symposium in Sydney today! #COMBINE19 https://t.co/ydE8RUc2Yd | 4 |
| combine_au | Tingtimg Gong from @GarvanInstitute talks about challenges in calling somatic structural variants and demonstrates that more is better when it comes to using variant callers. #combine19 @combine_au https://t.co/8cUdGPeFqt | 4 |
| LinYingxin | Ready for the three-day bioinformatics and computational biology conference in Sydney? 👩💻🧑💻 14 hours left for COMBINE/AYRCOB student symposium 2019 registration open! 😎#ABACBSGIW19 #combine19 #abacbs @combine_au @abacbs https://t.co/AoJ8uvJwAK | 4 |
| shazanfar |
Congrats to the excellent organisers of #combine19 & all @combine_au members & exec for a fantastic year of “for students, by students” events. 2020 exec nominations are now open, I found it incredibly rewarding & highly recommend! #ABACBSGIW19 @abacbs https://t.co/REEA4BjOuU |
4 |
| screen_name | text | favorite_count |
|---|---|---|
| YiwenWang_Eva | Come to see me at Poster 49 to talk about multivariate methods dealing with batch effects in microbiome data #COMBINE19 https://t.co/c5Quo3dCOf | 38 |
| YiwenWang_Eva | Thanks for the chance to present my work #combine19 My poster is packed up and ready for ABACBS. 😉#ABACBSGIW19 https://t.co/i3l4anaUXH | 30 |
| AliciaOshlack | Today I’m following #combine19. If you are a computational biology or bioinformatics student you should get involved in this. I’ve had 3 Combine presidents in my group! | 26 |
| gabefoley | Thanks @combine_au for second place in the poster presentations! If you’re interested in ancestral sequence reconstruction and missed me today - come check out my talk tomorrow morning at @abacbs in Session 3c Proteomics / Metabolomics #COMBINE19 #ABACBSGIW19 https://t.co/MypibiOo41 | 23 |
| LinYingxin | Finally the long COMBINE day finished! 🎉Everything ran smoothly ☺Super happy to organise this fantastic symposium with @Katarina_Stuart and the symposium committee team! You are so amazing😉I would also like to thank all the presenters, judges, attendees and sponsors!#COMBINE19 https://t.co/xDdQyUPIP5 | 23 |
| askemdarling | First research poster presentation done ✅ #COMBINE19 https://t.co/JUo0bbZh4r | 22 |
| PatSullivann |
I really enjoyed presenting my poster on identifying splice-altering variants at #BioInfoSummer Next up: #COMBINE19 https://t.co/nVt1PoENZZ |
22 |
| combine_au | Congratulations to all the prize winners and thank you to all the judges for spending the day listening to all the talks and poster sessions! #combine19 https://t.co/QAskoXA58o | 19 |
| LinYingxin | Ready for the three-day bioinformatics and computational biology conference in Sydney? 👩💻🧑💻 14 hours left for COMBINE/AYRCOB student symposium 2019 registration open! 😎#ABACBSGIW19 #combine19 #abacbs @combine_au @abacbs https://t.co/AoJ8uvJwAK | 18 |
| LeganaFingerhut | Presenting my poster at #COMBINE19! Come talk to me about antimicrobial peptides, microbiomes, machine learning, genome-wide predictions, R, or R package development! @combine_au @abacbs spot 41! https://t.co/zx8ZKhAAAZ | 18 |
| screen_name | text | quote_count |
|---|---|---|
| JovMaksimovic | The @abacbs postdoc survey is closing tomorrow at the end of the #ABACBSGIW19 conference. If you are a newbie postdoc (#combine19), a veteran postdoc or postdoc-identifying please complete the survey and let ABACBS know how they can best support and advocate for you. https://t.co/sIObXAFeEP | 1 |
| shazanfar |
Added, thanks Andrew!! #BioInfoSummer OR @bioinfosummer OR #biocasia OR #abacbs OR @abacbs OR #GIWABACBS2019 OR #abacbs2019 OR #abacbs19 OR #COMBINE19 OR @combine_au OR #COMBINE2019 https://t.co/GcPXYQY7ML |
1 |
| HaniKim127 | Excited because today I will present CiteFuse for the second time! But more excited by a tweet from @DaniKim_02 (yes our names rhyme) #combine19 @combine_au #twinsdoresearch #CPC https://t.co/sCVtJO8z3o | 1 |
| combine_au | Fantastic! This year COMBINE is trialling a live streaming of the symposium. We hope that everyone can attend and benefit from the presentations. #combine19 @combine_au #LiveStreaming https://t.co/BeDs6eQvRi | 1 |
| fredjaya1 | Very humbled and thrilled to be awarded the third best poster at #COMBINE19! Overall a fantastic day facilitated by an amazing and dedicated team @combine_au https://t.co/3SObVQ7jrE | 1 |
| tsonika | Tyrone and Javier would love to discuss their work with you. Go say hello! #ABACBSGIW19 #COMBINE19 https://t.co/f22R3xhWcK | 1 |
| tpq__ | Here is a longer form explanation of why you should do CPM(counts + 1) and not CPM(counts) + 1 #COMBINE19 #ABACBSGIW19 https://t.co/ykrK36Pslp | 1 |
| screen_name | text | favorite_count |
|---|---|---|
| YiwenWang_Eva | Come to see me at Poster 49 to talk about multivariate methods dealing with batch effects in microbiome data #COMBINE19 https://t.co/c5Quo3dCOf | 38 |
| YiwenWang_Eva | Thanks for the chance to present my work #combine19 My poster is packed up and ready for ABACBS. 😉#ABACBSGIW19 https://t.co/i3l4anaUXH | 30 |
| gabefoley | Thanks @combine_au for second place in the poster presentations! If you’re interested in ancestral sequence reconstruction and missed me today - come check out my talk tomorrow morning at @abacbs in Session 3c Proteomics / Metabolomics #COMBINE19 #ABACBSGIW19 https://t.co/MypibiOo41 | 23 |
| LinYingxin | Finally the long COMBINE day finished! 🎉Everything ran smoothly ☺Super happy to organise this fantastic symposium with @Katarina_Stuart and the symposium committee team! You are so amazing😉I would also like to thank all the presenters, judges, attendees and sponsors!#COMBINE19 https://t.co/xDdQyUPIP5 | 23 |
| askemdarling | First research poster presentation done ✅ #COMBINE19 https://t.co/JUo0bbZh4r | 22 |
| PatSullivann |
I really enjoyed presenting my poster on identifying splice-altering variants at #BioInfoSummer Next up: #COMBINE19 https://t.co/nVt1PoENZZ |
22 |
| combine_au | Congratulations to all the prize winners and thank you to all the judges for spending the day listening to all the talks and poster sessions! #combine19 https://t.co/QAskoXA58o | 19 |
| LinYingxin | Ready for the three-day bioinformatics and computational biology conference in Sydney? 👩💻🧑💻 14 hours left for COMBINE/AYRCOB student symposium 2019 registration open! 😎#ABACBSGIW19 #combine19 #abacbs @combine_au @abacbs https://t.co/AoJ8uvJwAK | 18 |
| LeganaFingerhut | Presenting my poster at #COMBINE19! Come talk to me about antimicrobial peptides, microbiomes, machine learning, genome-wide predictions, R, or R package development! @combine_au @abacbs spot 41! https://t.co/zx8ZKhAAAZ | 18 |
| MarcelDinger | Thanks @combine_au for the hospitality and awesome jacaranda snow globe - love it :) #COMBINE19 https://t.co/l6J1W6UY1J | 17 |
The top 100 words used 3 or more times.
Words that were tweeted next to each other at least 3 times.
Top 10 words associated with 6 topics identified by LDA.
Most representative tweets for each topic
| screen_name | text | gamma |
|---|---|---|
| BradBalderson3 | log2(CPT+1) or log2(CPT(count+1)) for scRNA-seq, question by @tpq__ at #COMBINE19 to @rafalab. Tried both using data simulated with splatter. Problem with latter pseudocount is that value<1 results in log2(value)<0. Therefore 0!=0 across cells, so log2(CPT+1) wins. https://t.co/QJocuVyiMy | 0.9965241 |
| JovMaksimovic | The @abacbs postdoc survey is closing tomorrow at the end of the #ABACBSGIW19 conference. If you are a newbie postdoc (#combine19), a veteran postdoc or postdoc-identifying please complete the survey and let ABACBS know how they can best support and advocate for you. https://t.co/sIObXAFeEP | 0.9955073 |
| LeganaFingerhut | Presenting my poster at #COMBINE19! Come talk to me about antimicrobial peptides, microbiomes, machine learning, genome-wide predictions, R, or R package development! @combine_au @abacbs spot 41! https://t.co/zx8ZKhAAAZ | 0.9945509 |
| PNgsabrina | @fredjaya1 on using bioinformatics to study cryptic species of Australian toads 🐸 Cool infographics for a fast-forward talk at #COMBINE19 https://t.co/yEwwygvXrs | 0.9936496 |
| YiwenWang_Eva | Come to see me at Poster 49 to talk about multivariate methods dealing with batch effects in microbiome data #COMBINE19 https://t.co/c5Quo3dCOf | 0.9923912 |
| abacbs | Hani Jieun Kim presenting some work on the multi-modal analysis of CITE-seq data #combine19 | 0.9915543 |
| JasonJinxin | Want to know more B cell acute lymphoblastic leukemia? Come to see Feng @alexyfyf at #COMBINE19 #combine_au poster 47 https://t.co/HNI7j3juxe | 0.9905106 |
| PNgsabrina | Fast forward talk is up! And yes, I would love stability in my genes too 😂 #COMBINE19 https://t.co/9n90q7hnCJ | 0.9891726 |
| MarcelDinger | Thanks @combine_au for the hospitality and awesome jacaranda snow globe - love it :) #COMBINE19 https://t.co/l6J1W6UY1J | 0.9891726 |
| wessidepraxis | Genome graph must be on the bioinformatics conference bingo card #combine19 | 0.9873953 |
| Katarina_Stuart | Excellent talk by Hani Kim on CiteFuse #COMBINE19 https://t.co/Ss10jZv91S | 0.9873953 |
| screen_name | text | gamma |
|---|---|---|
| combine_au | @NhiHin use zebra fish to model familial Alzheimer’s disease and demonstrate the alteration in iron homeostasis by comparing differences in the transcriptome of iron response element gene sets. @combine_au #combine19 https://t.co/iy2OCf9ess | 0.9959780 |
| LinYingxin | Ready for the three-day bioinformatics and computational biology conference in Sydney? 👩💻🧑💻 14 hours left for COMBINE/AYRCOB student symposium 2019 registration open! 😎#ABACBSGIW19 #combine19 #abacbs @combine_au @abacbs https://t.co/AoJ8uvJwAK | 0.9952281 |
| shazanfar | After an excellent set of student talks and posters at #combine19 we are now officially opening the #ABACBSGIW19 conference. Beginning with a Welcome to Country here on indigenous Cadigal land of the Eora country | 0.9949120 |
| abacbs | Up next is Maria Satti (National Institute of Genetics, Japan) talking about comparative genomics of Bifidobacterium from Egyptian fuit bats #combine19 | 0.9941347 |
| lazappi | Adding #eurobioc2019 to my Tweetdeck search with #BioInfoSummer OR @Bioinfosummer OR #biocasia OR #abacbs OR @abacbs OR #GIWABACBS2019 OR #abacbs2019 OR #abacbs19 OR #COMBINE19 OR @combine_au OR #COMBINE2019 for 24 #bioinformatics conference action. | 0.9936496 |
| shazanfar | And we’re well into the morning session of the #combine19 student symposium, a key part of @abacbs #ABACBSGIW19 Excellent presentations (both talks and posters) by students/ECRs today! | 0.9936496 |
| em6wong | Looking forward to #combine19 student/ECR symposium and having a chat about science careers this afternoon at the careers panel! #ABACBSGIW19 | 0.9930771 |
| SeqComplete | #bioinformatics #bioit @PNgsabrina: ‘Stunning slides by @NhiHin from the @UofABioinfoHub on understanding Alzheimer’s disease via #bioinformatics at @combine_au #COMBINE19’ https://t.co/6IZctcnDLS, see more https://t.co/X2bD5F4Rqm | 0.9930771 |
| abacbs | Rachael Bowen-James starting the mid-morning session by talking about Cancer Genomics compression #combine19 | 0.9930771 |
| abacbs | Ahmed Zeeshan Siddiqui (UNSW) is now talking about tissue-specific cirRNAs in normal healthy humans. #combine19 | 0.9930771 |
| screen_name | text | gamma |
|---|---|---|
| LonsBio | Great start to #combine19 with @rfroum characterising whether CRISPR-Cas is active in resistance Klebsiella pneumoniae. No time for questions, but we have Twitter! Any known limitations in the CRISPRCasFinder (e.g. FPs or FNs) when locating the cassettes? | 0.9959780 |
| shazanfar |
Congrats to the excellent organisers of #combine19 & all @combine_au members & exec for a fantastic year of “for students, by students” events. 2020 exec nominations are now open, I found it incredibly rewarding & highly recommend! #ABACBSGIW19 @abacbs https://t.co/REEA4BjOuU |
0.9955073 |
| LonsBio | #COMBINE19 awards for posters, lightning talks and talks! Nice having the judges presenting the prizes. Unable to split a few of the winners, multiple prizes! #ABACBSGIW19 | 0.9945509 |
| shazanfar | Congratulations to the excellent presenters (talk, lightning talk and poster) today at #combine19 !! It was a pleasure to hear all the fantastic science, but incredibly difficult to judge! | 0.9945509 |
| fredjaya1 | Who else is excited for a massive week of bioinformatics? The first of presentation I’ll be giving will be a fast forward talk on frogs at #COMBINE19, come and check it out! 🐸🧬 #ABACBSGIW19 https://t.co/Y6xjqNKPxY | 0.9941347 |
| askemdarling | Awesome to hear @rfroum talk about her Masters research project on CRISPR-CAS activity in Kp #COMBINE19 https://t.co/4eg6TDoXOi | 0.9936496 |
| combine_au | Tingtimg Gong from @GarvanInstitute talks about challenges in calling somatic structural variants and demonstrates that more is better when it comes to using variant callers. #combine19 @combine_au https://t.co/8cUdGPeFqt | 0.9936496 |
| combine_au | The first speaker of #combine19, @rfroum gives us insight into the diversity of CRISPR activity in Klebsiella pneumoniae genome. Thank you for the talk! https://t.co/lUSd7BCJ7s | 0.9930771 |
| abacbs | Ilariya Tarasova (WEHII) is up next presenting the exploration of time and division-dependent gene expression during B cell division #combine19 | 0.9930771 |
| abacbs | Next up is Tingting Gong (Garvan) talking about somatic structural variant detection and annotation in cancer samples #combine19 | 0.9930771 |
| combine_au | Congratulations to all the prize winners and thank you to all the judges for spending the day listening to all the talks and poster sessions! #combine19 https://t.co/QAskoXA58o | 0.9930771 |
| screen_name | text | gamma |
|---|---|---|
| JovMaksimovic | For everyone who will be attending the @abacbs post doc event at 6pm tonight in the beer garden at the Alfred Hotel (https://t.co/qzQ8iLSUtt) there will be a bar tab! Enjoy the 🍻 and say “Hi!” to Ignatius Pang who has kindly stepped in to host in my stead #combine19 #ABACBSGIW19 | 0.9963593 |
| LinYingxin | Finally the long COMBINE day finished! 🎉Everything ran smoothly ☺Super happy to organise this fantastic symposium with @Katarina_Stuart and the symposium committee team! You are so amazing😉I would also like to thank all the presenters, judges, attendees and sponsors!#COMBINE19 https://t.co/xDdQyUPIP5 | 0.9961781 |
| PNgsabrina | An adaptation from the #betterposter concept, I will be presenting my poster at #COMBINE19 on my recently published work as a co-first author. Using tRNA-seq, RNA-seq, Proteomics data - a case study on how modification changes can affect protein translation. @combine_au @abacbs https://t.co/BRE69dSa5m | 0.9959780 |
| rnomics | https://t.co/3pvgrx66XZ PNgsabrina: ’An adaptation from the #betterposter concept, I will be presenting my poster at #COMBINE19 on my recently published work as a co-first author. Using tRNA-seq, RNA-seq, Proteomics data - a case study on how modification changes can affect pro… | 0.9957556 |
| LonsBio | @combine_au This is arguably the 10th @combine_au symposium - the existence of the second is hotly debated amongst COMBINE historians, but a truce has been declared by accepting there could be an off by one error! From humble beginnings… #combine19 https://t.co/4prr6tKHZ7 | 0.9949120 |
| abacbs | Alassandra Whaite from the University of the Sunshine Coast presenting proteomic work on natural protein fibers from molluscs and spiders. Facinating area of study! #combine19 | 0.9941347 |
| Katarina_Stuart | Alessandra Whaite wow-ing us all with her spider and oyster wrangling skills #COMBINE19 https://t.co/Pe2imcZhfZ | 0.9915543 |
| IgnatiusPang | GIW/ABACBS Conference dinner still open until end of tonight. Please speak to registrations desk if you want to get a ticket. #ABACBSGIW19 #COMBINE19 | 0.9915543 |
| combine_au | Next up is @gerrythill talking about limitations of current pangenomic analytical tools! What goes in must come out! #combine19 https://t.co/bDfyJlfIzj | 0.9905106 |
| AusBiocommons | We’re so pleased to be sponsoring and attending the @combine_au Symposium in Sydney today! #COMBINE19 https://t.co/ydE8RUc2Yd | 0.9891726 |
| screen_name | text | gamma |
|---|---|---|
| combine_au | Machine learning on breast cancer genomic data. Richard Lupat demonstrates the use of deep learning based models to classify breast cabcer cell types. @combine_au #combine19 @PeterMacCC https://t.co/52GQDuq5Hg | 0.9961781 |
| LonsBio | Great talk by Richard Lupat from @PeterMacRes on using autoencoders to find relevant features for further model building to classify breast cancers from high dimensional genomic data #combine19 | 0.9949120 |
| abacbs | Richard Lupat (Peter MacCullum Cancer Centre) talking about Deep Learning for feature etraction in Breast Cancer data #combine19 | 0.9945509 |
| combine_au | Fantastic! This year COMBINE is trialling a live streaming of the symposium. We hope that everyone can attend and benefit from the presentations. #combine19 @combine_au #LiveStreaming https://t.co/BeDs6eQvRi | 0.9936496 |
| abacbs | We also had a very cool talk from Marina Reixachs (ANU) on ribosomal profiling on isoforms. Always hard being the first talk after lunch #combine19 #sofull | 0.9936496 |
| shazanfar |
Although the #combine19 program is not yet over! See the program for the remaining events for today: careers panel & social event Students at #ABACBSGIW19 take note! |
0.9936496 |
| LonsBio | That’s two #COMBINE19 talks so far today mentioning autoencoders, will have to pick the brains of @rlupat and @pabloacera91 at lunch time - seems a very useful technique for biological applications | 0.9936496 |
| HaniKim127 | Excited because today I will present CiteFuse for the second time! But more excited by a tweet from @DaniKim_02 (yes our names rhyme) #combine19 @combine_au #twinsdoresearch #CPC https://t.co/sCVtJO8z3o | 0.9930771 |
| samleechch | Very good representation of what autoencoders want to do from PAO’s talk on deep learning over @nanopore signal data #combine19 https://t.co/N41mYIrP5F | 0.9923912 |
| PNgsabrina | Interesting deep clustering #MachineLearning approach by Pablos to detect modifications on nanopore reads #COMBINE19 https://t.co/t2XwRnHNwY | 0.9923912 |
| screen_name | text | gamma |
|---|---|---|
| dumeir | Started #COMBINE19 with an excellent presentation by my friend @rfroum and ended with an insightful career panel by @rafalab, @MarcelDinger, Dr Denis Bauer and Dr Emily Wong. Thank you @combine_au for allowing me to be an abstract reviewer and see you tomorrow for #ABACBSGIW19! | 0.9961781 |
| YiwenWang_Eva | Do you wanna to simulate more scenarios in gene family evolution? Then you cannot miss the talk of Qiuyi. He introduces a new model called IxDTL. Well done! Qiuyi! #COMBINE19 @QiuyiLi2 @MelbIntGen https://t.co/OK3AU73Z93 | 0.9955073 |
| gabefoley | Thanks @combine_au for second place in the poster presentations! If you’re interested in ancestral sequence reconstruction and missed me today - come check out my talk tomorrow morning at @abacbs in Session 3c Proteomics / Metabolomics #COMBINE19 #ABACBSGIW19 https://t.co/MypibiOo41 | 0.9952281 |
| abacbs | Quiyi Li (UniMelbourne) talking about “IxDTL a flexible model of gene family evolution”. Love the beamer slides #latex #respect #combine19 | 0.9949120 |
| abacbs | Gerry Tonkin-Hill from the Sanger Centre (UK) presenting a cautionary tale of errors and contamination in bacterial Pangenome analyses #combine19 | 0.9941347 |
| SameOld_SamOld | Presenting my poster at #combine19 today! Come see me to hear about doing a deep dive on bulk RNA-Seq to characterise rare cells using my Shiny app ☺ https://t.co/dMVmSudbjD | 0.9941347 |
| LinYingxin | COMBINE/AYRCOB symposium career panel starts now 🤩 panelists include @rafalab @MarcelDinger @allPowerde @em6wong #COMBINE19 https://t.co/NHfgwQet5o | 0.9930771 |
| abacbs | Xiangnan Xu (USyd) rounding off the session with his talk on Nutrigenomics data analysis #combine19 | 0.9915543 |
| Katarina_Stuart | Xiqngnan Xu closing off the COMBINE 2019 student talks with his presentation on nutrigenomics #COMBINE19 https://t.co/PyRnHu0vF3 | 0.9915543 |
| combine_au | Thank you @marinareixachs from the ANU and Ahmad Siddiqui from @UNSW for opening the third and last session of the COMBINE symposium. #combine19 https://t.co/lh7UIBxEBo | 0.9905106 |
| AZadoorian22 | Thanks @rafalab, @MarcelDinger, @allPowerde and @em6wong for all your excellent advice at the #combine19 @CPC_EMCR career panel tonight! https://t.co/PCgAcJ4tyW | 0.9905106 |
Links to GitHub, GitLab, BitBucket, Bioconductor or CRAN mentioned in Tweets.
## ─ Session info ───────────────────────────────────────────────────────────────
## setting value
## version R version 4.0.0 (2020-04-24)
## os macOS Catalina 10.15.6
## system x86_64, darwin17.0
## ui X11
## language (EN)
## collate en_US.UTF-8
## ctype en_US.UTF-8
## tz Europe/Berlin
## date 2020-09-01
##
## ─ Packages ───────────────────────────────────────────────────────────────────
## package * version date lib source
## askpass 1.1 2019-01-13 [1] CRAN (R 4.0.0)
## assertthat 0.2.1 2019-03-21 [1] CRAN (R 4.0.0)
## backports 1.1.8 2020-06-17 [1] CRAN (R 4.0.0)
## bitops 1.0-6 2013-08-17 [1] CRAN (R 4.0.0)
## callr 3.4.3 2020-03-28 [1] CRAN (R 4.0.0)
## clamour * 0.1.0 2020-09-01 [1] Github (lazappi/clamour@c8ea1c7)
## cli 2.0.2 2020-02-28 [1] CRAN (R 4.0.0)
## colorspace 1.4-1 2019-03-18 [1] CRAN (R 4.0.0)
## crayon 1.3.4 2017-09-16 [1] CRAN (R 4.0.0)
## curl 4.3 2019-12-02 [1] CRAN (R 4.0.0)
## digest 0.6.25 2020-02-23 [1] CRAN (R 4.0.0)
## dplyr * 1.0.1 2020-07-31 [1] CRAN (R 4.0.2)
## ellipsis 0.3.1 2020-05-15 [1] CRAN (R 4.0.0)
## emo * <IP_ADDRESS>00 2020-08-17 [1] Github (hadley/emo@3f03b11)
## evaluate 0.14 2019-05-28 [1] CRAN (R 4.0.0)
## fansi 0.4.1 2020-01-08 [1] CRAN (R 4.0.0)
## farver 2.0.3 2020-01-16 [1] CRAN (R 4.0.0)
## forcats * 0.5.0 2020-03-01 [1] CRAN (R 4.0.0)
## fs * 1.5.0 2020-07-31 [1] CRAN (R 4.0.2)
## generics 0.0.2 2018-11-29 [1] CRAN (R 4.0.0)
## ggforce 0.3.2 2020-06-23 [1] CRAN (R 4.0.2)
## ggplot2 * 3.3.2 2020-06-19 [1] CRAN (R 4.0.2)
## ggraph * 2.0.3 2020-05-20 [1] CRAN (R 4.0.0)
## ggrepel * 0.8.2 2020-03-08 [1] CRAN (R 4.0.0)
## ggtext * 0.1.0 2020-06-04 [1] CRAN (R 4.0.2)
## glue 1.4.1 2020-05-13 [1] CRAN (R 4.0.0)
## graphlayouts 0.7.0 2020-04-25 [1] CRAN (R 4.0.0)
## gridExtra 2.3 2017-09-09 [1] CRAN (R 4.0.0)
## gridtext 0.1.1 2020-02-24 [1] CRAN (R 4.0.2)
## gtable 0.3.0 2019-03-25 [1] CRAN (R 4.0.0)
## here * 0.1 2017-05-28 [1] CRAN (R 4.0.0)
## highr 0.8 2019-03-20 [1] CRAN (R 4.0.0)
## htmltools 0.5.0 2020-06-16 [1] CRAN (R 4.0.0)
## httr 1.4.2 2020-07-20 [1] CRAN (R 4.0.2)
## igraph * 1.2.5 2020-03-19 [1] CRAN (R 4.0.0)
## janeaustenr 0.1.5 2017-06-10 [1] CRAN (R 4.0.0)
## jsonlite 1.7.0 2020-06-25 [1] CRAN (R 4.0.0)
## kableExtra * 1.2.1 2020-08-27 [1] CRAN (R 4.0.2)
## knitr * 1.29 2020-06-23 [1] CRAN (R 4.0.0)
## labeling 0.3 2014-08-23 [1] CRAN (R 4.0.0)
## lattice 0.20-41 2020-04-02 [1] CRAN (R 4.0.0)
## lifecycle 0.2.0 2020-03-06 [1] CRAN (R 4.0.0)
## lubridate * 1.7.9 2020-06-08 [1] CRAN (R 4.0.0)
## magick * 2.4.0 2020-06-23 [1] CRAN (R 4.0.0)
## magrittr 1.5 2014-11-22 [1] CRAN (R 4.0.0)
## markdown 1.1 2019-08-07 [1] CRAN (R 4.0.0)
## MASS 7.3-51.6 2020-04-26 [1] CRAN (R 4.0.0)
## Matrix 1.2-18 2019-11-27 [1] CRAN (R 4.0.0)
## modeltools 0.2-23 2020-03-05 [1] CRAN (R 4.0.0)
## munsell 0.5.0 2018-06-12 [1] CRAN (R 4.0.0)
## NLP 0.2-0 2018-10-18 [1] CRAN (R 4.0.0)
## openssl 1.4.2 2020-06-27 [1] CRAN (R 4.0.0)
## pillar 1.4.6 2020-07-10 [1] CRAN (R 4.0.2)
## pkgconfig 2.0.3 2019-09-22 [1] CRAN (R 4.0.0)
## plyr 1.8.6 2020-03-03 [1] CRAN (R 4.0.0)
## png 0.1-7 2013-12-03 [1] CRAN (R 4.0.0)
## polyclip 1.10-0 2019-03-14 [1] CRAN (R 4.0.0)
## processx 3.4.3 2020-07-05 [1] CRAN (R 4.0.2)
## ps 1.3.3 2020-05-08 [1] CRAN (R 4.0.0)
## purrr * 0.3.4 2020-04-17 [1] CRAN (R 4.0.0)
## R6 2.4.1 2019-11-12 [1] CRAN (R 4.0.0)
## RColorBrewer * 1.1-2 2014-12-07 [1] CRAN (R 4.0.0)
## Rcpp 1.0.5 2020-07-06 [1] CRAN (R 4.0.0)
## RCurl 1.98-1.2 2020-04-18 [1] CRAN (R 4.0.0)
## reshape2 1.4.4 2020-04-09 [1] CRAN (R 4.0.0)
## rlang 0.4.7 2020-07-09 [1] CRAN (R 4.0.2)
## rmarkdown 2.3 2020-06-18 [1] CRAN (R 4.0.0)
## rprojroot 1.3-2 2018-01-03 [1] CRAN (R 4.0.0)
## rstudioapi 0.11 2020-02-07 [1] CRAN (R 4.0.0)
## rtweet * 0.7.0 2020-01-08 [1] CRAN (R 4.0.0)
## rvest * 0.3.6 2020-07-25 [1] CRAN (R 4.0.2)
## scales 1.1.1 2020-05-11 [1] CRAN (R 4.0.0)
## selectr 0.4-2 2019-11-20 [1] CRAN (R 4.0.0)
## sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 4.0.0)
## slam 0.1-47 2019-12-21 [1] CRAN (R 4.0.0)
## SnowballC 0.7.0 2020-04-01 [1] CRAN (R 4.0.0)
## stringi 1.4.6 2020-02-17 [1] CRAN (R 4.0.0)
## stringr * 1.4.0 2019-02-10 [1] CRAN (R 4.0.0)
## tibble 3.0.3 2020-07-10 [1] CRAN (R 4.0.2)
## tidygraph 1.2.0 2020-05-12 [1] CRAN (R 4.0.0)
## tidyr * 1.1.1 2020-07-31 [1] CRAN (R 4.0.2)
## tidyselect 1.1.0 2020-05-11 [1] CRAN (R 4.0.0)
## tidytext * 0.2.5 2020-07-11 [1] CRAN (R 4.0.2)
## tm 0.7-7 2019-12-12 [1] CRAN (R 4.0.0)
## tokenizers 0.2.1 2018-03-29 [1] CRAN (R 4.0.0)
## topicmodels * 0.2-11 2020-04-19 [1] CRAN (R 4.0.0)
## tweenr 1.0.1 2018-12-14 [1] CRAN (R 4.0.0)
## usethis 1.6.1 2020-04-29 [1] CRAN (R 4.0.0)
## utf8 1.1.4 2018-05-24 [1] CRAN (R 4.0.0)
## vctrs 0.3.2 2020-07-15 [1] CRAN (R 4.0.2)
## viridis * 0.5.1 2018-03-29 [1] CRAN (R 4.0.0)
## viridisLite * 0.3.0 2018-02-01 [1] CRAN (R 4.0.0)
## webshot * 0.5.2 2019-11-22 [1] CRAN (R 4.0.0)
## withr 2.2.0 2020-04-20 [1] CRAN (R 4.0.0)
## wordcloud * 2.6 2018-08-24 [1] CRAN (R 4.0.0)
## xfun 0.16 2020-07-24 [1] CRAN (R 4.0.2)
## xml2 * 1.3.2 2020-04-23 [1] CRAN (R 4.0.0)
## yaml 2.2.1 2020-02-01 [1] CRAN (R 4.0.0)
##
## [1] /Library/Frameworks/R.framework/Versions/4.0/Resources/library


The TaskManager module is a mixin for managing tasks.
Track the last comment made in the Rakefile.
Track the last comment made in the Rakefile.
# File lib/rake/task_manager.rb, line 9 def initialize super @tasks = Hash.new @rules = Array.new @scope = Array.new @last_description = nil end
Find a matching task for task_name
.
# File lib/rake/task_manager.rb, line 44 def [](task_name, scopes=nil) task_name = task_name.to_s self.lookup(task_name, scopes) or enhance_with_matching_rule(task_name) or synthesize_file_task(task_name) or fail "Don't know how to build task '#{task_name}'" end
Clear all tasks in this application.
# File lib/rake/task_manager.rb, line 146 def clear @tasks.clear @rules.clear end
# File lib/rake/task_manager.rb, line 17 def create_rule(*args, &block) pattern, _, deps = resolve_args(args) pattern = Regexp.new(Regexp.quote(pattern) + '$') if String === pattern @rules << [pattern, deps, block] end
Return the list of scope names currently active in the task manager.
# File lib/rake/task_manager.rb, line 186 def current_scope @scope.dup end
# File lib/rake/task_manager.rb, line 23 def define_task(task_class, *args, &block) task_name, arg_names, deps = resolve_args(args) task_name = task_class.scope_name(@scope, task_name) deps = [deps] unless deps.respond_to?(:to_ary) deps = deps.collect {|d| d.to_s } task = intern(task_class, task_name) task.set_arg_names(arg_names) unless arg_names.empty? if Rake::TaskManager.record_task_metadata add_location(task) task.add_description(get_description(task)) end task.enhance(deps, &block) end
If a rule can be found that matches the task name, enhance the task with the prerequisites and actions from the rule. Set the source attribute of the task appropriately for the rule. Return the enhanced task or nil of no rule was found.
# File lib/rake/task_manager.rb, line 116 def enhance_with_matching_rule(task_name, level=0) fail Rake::RuleRecursionOverflowError, "Rule Recursion Too Deep" if level >= 16 @rules.each do |pattern, extensions, block| if pattern.match(task_name) task = attempt_rule(task_name, extensions, block, level) return task if task end end nil rescue Rake::RuleRecursionOverflowError => ex ex.add_target(task_name) fail ex end
Evaluate the block in a nested namespace named name
. Create
an anonymous namespace if name
is nil.
# File lib/rake/task_manager.rb, line 192 def in_namespace(name) name ||= generate_name @scope.push(name) ns = NameSpace.new(self, @scope) yield(ns) ns ensure @scope.pop end
Lookup a task. Return an existing task if found, otherwise create a task of the current type.
# File lib/rake/task_manager.rb, line 39 def intern(task_class, task_name) @tasks[task_name.to_s] ||= task_class.new(task_name, self) end
Lookup a task, using scope and the scope hints in the task name. This method performs straight lookups without trying to synthesize file tasks or rules. Special scope names (e.g. ‘^’) are recognized. If no scope argument is supplied, use the current scope. Return nil if the task cannot be found.
# File lib/rake/task_manager.rb, line 156 def lookup(task_name, initial_scope=nil) initial_scope ||= @scope task_name = task_name.to_s if task_name =~ /^rake:/ scopes = [] task_name = task_name.sub(/^rake:/, '') elsif task_name =~ /^(\^+)/ scopes = initial_scope[0, initial_scope.size - $1.size] task_name = task_name.sub(/^(\^+)/, '') else scopes = initial_scope end lookup_in_scope(task_name, scopes) end
Resolve the arguments for a task/rule. Returns a triplet of [task_name, arg_name_list, prerequisites].
# File lib/rake/task_manager.rb, line 59 def resolve_args(args) if args.last.is_a?(Hash) deps = args.pop resolve_args_with_dependencies(args, deps) else resolve_args_without_dependencies(args) end end
# File lib/rake/task_manager.rb, line 52 def synthesize_file_task(task_name) return nil unless File.exist?(task_name) define_task(Rake::FileTask, task_name) end
List of all defined tasks in this application.
# File lib/rake/task_manager.rb, line 132 def tasks @tasks.values.sort_by { |t| t.name } end
List of all the tasks defined in the given scope (and its sub-scopes).
# File lib/rake/task_manager.rb, line 138 def tasks_in_scope(scope) prefix = scope.join(":") tasks.select { |t| /^#{prefix}:/ =~ t.name } end
Add a location to the locations field of the given task.
# File lib/rake/task_manager.rb, line 205 def add_location(task) loc = find_location task.locations << loc if loc task end
Attempt to create a rule given the list of prerequisites.
# File lib/rake/task_manager.rb, line 234 def attempt_rule(task_name, extensions, block, level) sources = make_sources(task_name, extensions) prereqs = sources.collect { |source| trace_rule level, "Attempting Rule #{task_name} => #{source}" if File.exist?(source) || Rake::Task.task_defined?(source) trace_rule level, "(#{task_name} => #{source} ... EXIST)" source elsif parent = enhance_with_matching_rule(source, level+1) trace_rule level, "(#{task_name} => #{source} ... ENHANCE)" parent.name else trace_rule level, "(#{task_name} => #{source} ... FAIL)" return nil end } task = FileTask.define_task({task_name => prereqs}, &block) task.sources = prereqs task end
Find the location that called into the dsl layer.
# File lib/rake/task_manager.rb, line 212 def find_location locations = caller i = 0 while locations[i] return locations[i+1] if locations[i] =~ /rake\/dsl_definition.rb/ i += 1 end nil end
Generate an anonymous namespace name.
# File lib/rake/task_manager.rb, line 223 def generate_name @seed ||= 0 @seed += 1 "_anon_#{@seed}" end
Return the current description, clearing it in the process.
# File lib/rake/task_manager.rb, line 284 def get_description(task) desc = @last_description @last_description = nil desc end
Lookup the task name
# File lib/rake/task_manager.rb, line 172 def lookup_in_scope(name, scope) n = scope.size while n >= 0 tn = (scope[0,n] + [name]).join(':') task = @tasks[tn] return task if task n -= 1 end nil end
Make a list of sources from the list of file name extensions / translation procs.
# File lib/rake/task_manager.rb, line 256 def make_sources(task_name, extensions) result = extensions.collect { |ext| case ext when /%/ task_name.pathmap(ext) when %r{/} ext when /^\./ task_name.ext(ext) when String ext when Proc if ext.arity == 1 ext.call(task_name) else ext.call end else fail "Don't know how to handle rule dependent: #{ext.inspect}" end } result.flatten end
Resolve task arguments for a task or rule when there are no dependencies declared.
The patterns recognized by this argument resolving function are:
task :t task :t, [:a]
# File lib/rake/task_manager.rb, line 76 def resolve_args_without_dependencies(args) task_name = args.shift if args.size == 1 && args.first.respond_to?(:to_ary) arg_names = args.first.to_ary else arg_names = args end [task_name, arg_names, []] end
# File lib/rake/task_manager.rb, line 229 def trace_rule(level, message) options.trace_output.puts "#{" "*level}#{message}" if Rake.application.options.trace_rules end


Guide to making dygraphs changes
So you've made a change to dygraphs and would like to contribute it back
to the open source project. Wonderful!
This is a step-by-step guide explaining how to do it.
dygraphs style
First of all, please try to follow the style of the existing dygraphs
code. This will make the review process go much more smoothly.
A few salient points:
- We try to adhere to Google's
JS style guide and would appreciate it if you try to as well. This
means:
- No tabs! Indent using two spaces.
- Use camelCase for variable and function names.
- Limit lines to 80 characters.
- Please run 'lint.sh' to see if you've introduced any new violations.
- If you've added a new feature, add a test for it (in the tests/
directory) or a gallery entry.
- If you've added an option, document it in
dygraph-options-reference.js. You'll get lots of warnings if you don't.
- If you've fixed a bug or added a feature, add an auto_test for
it.
This ensures that we won't inadvertently break your feature in the
future. To do this, either add to an existing auto_test in
auto_tests/tests or run
auto_tests/misc/new-test.sh your-test-name
to
create a new one. There are two easy ways to run tests:
- You can run your auto_test in any browser by visiting
auto_tests/misc/local.html
. This allows you to debug your
test, or test against a specific browser.
- You can run your auto_test on the command-line by running
./test.sh
. (It requires installing
phantomjs on your computer.)
Sending a Pull Request
dygraphs is hosted on github, which uses a "pull request" model. They
have a good writeup here. These
instructions discuss dygraphs more specifically.
The list of steps may look a bit daunting, but it's not too bad,
especially if you have any familiarity with git or github. If you run into
any problems while following the instructions, feel free to contact
dygraphs-users.
Why not just take patches? This process means less work for me (the
maintainer) and it also results in your name appearing in the list of
dygraphs commits. This lets you take credit for your work.
- Create an account on github. This is
free, painless and will let you claim credit for your changes.
- Install git. github has a good writeup here.
- Create a fork of the dygraphs repository on github by
clicking this link and
then the "Fork" button.
- You should see a URL along the lines of
git@github.com:yourname/dygraphs.git
Copy this, open up a
terminal and run
git clone git@github.com:yourname/dygraphs.git
This
pulls the dygraphs code down onto your local disk.
- cd into the dygraphs directory and make your changes.
If you've already got them somewhere else, just copy them over.
- Be a good citizen! Make sure your code follows the guidelines
above.
You'll have to do this before we accept your changes, so you may as well
do it now
- Commit your changes locally: run
git add .
git commit
Type in a description of your change. This will
eventually appear in the dygraphs commit list.
- Push your changes to github by running
git push
This will
send your changes to your forked repository on github.
- Go to your fork of dygraphs on github (i.e.
github.com/yourname/dygraphs).
Click the "Pull Request" button.
This will send me an email with a pointer to your changes.
- We'll review your changes and (unless your code is perfect!) give you
some feedback. Make these suggested changes in your local git client and
re-run "git commit" and "git push" so that we can see them.
- Once your change is ready, we'll pull it into the main dygraphs
repository and publish it to the web.


YOUR BUSINESS MANAGEMENT
Call Us - UAN NUMBER : 555-3332-212/555-3BIZMA
Name
Email
Organization
Message


Home
Labs
GH Repo
Start
Press the "Start" to begin.
Stop
"Stop" to finish.
https://
your-tide-app.com
Tweets about
Rust ( @rustlang )
and
http-rs( @_httprs )


Conference Proceedings
Comparative Analysis of Machine Learning Methods in Anomaly-based Intrusion Detection
Niluka Piyasinghe, Anuradhe Kadurugasyaya, Harsha Karunatissa
Read the Abstract
View Presentation
Accelerating Mutual Information Analysis Based Power Analysis Attacks using the GPU
Malin Prematilake, Buddhi Wickramasinghe, Olitha Vithanage
Read the Abstract
View Presentation
Posters from the Project Symposium
Third Engineering Students' Conference at Peradeniya


{% extends "polls/base.html" %} {% block title %}
Participants who voted {{Question.option1}} :{{count.option1}}
Participants who voted {{Question.option2}} :{{count.option2}}
Participants who voted {{Question.option3}} :{{count.option3}}
Participants who voted {{Question.option4}} :{{count.option4}}


Ma vie en rose (1997)
Director: Alain Berliner Cast: Michele Laroque, Jean-Philippe Ecoffey, Helene Vincent, Georges Du Fresne, Daniel Hanssens, Laurence Bibot Screenplay: Alain Berliner, Chris van der Stappen Producers: Carole Scotta Runtime: 88 min US Distribution: Sony Pictures Classics Rated R: brief strong language
By Nathaniel R. Atcheson<EMAIL_ADDRESS>Ma vie en rose (My Life in Pink) is a quaint, direct film that tells the story of a nine year-old boy named Ludo (Georges Du Fresne) who finds pleasure dressing up like a girl. His parents, Pierre (Jean-Philippe Ecoffey) and Hanna (Michele Laroque), discover this one uncomfortable day when he emerges during a party dressed in his sister's pink dress. At first, they think it's just a phase. But Ludo keeps talking about it, and soon they have him seeing a child psychiatrist.
Ludo, in his young age, doesn't understand the implications of the things he does and says. A neighborhood friend of his is also the son of Pierre's boss; when Ludo tells his friend that he wants to marry him someday, the neighborhood finds out and goes into social upheaval, immediately assuming that Ludo's parents have raised him in some foul manner. The final straw occurs when Ludo--unbeknownst to everyone--takes the part of Sleeping Beauty in the school play so he can be kissed by Prince Charming.
Ma vie en rose was written and directed by Belgian filmmaker Alain Berliner. He has created a good film here: it is successful because it shows clearly the perspectives of both the children and the parents in the story. Berliner presents the material in such a way that it is completely inoffensive from the beginning--even those who agree with the ethics challenged in this film are not likely to be offended. It's positive, actually, that the subject matter is not off-putting, because it makes the film more accessible, and allows us to focus on the characters rather than a contrived plot (which, unfortunately, is what most American films dealing with cross dressing offer).
A film like this relies heavily on the acting, and the central performance from the young Georges Du Fresne is an excellent one; Ludo, at the same time, is a fascinating character. He knows so certainly what is natural to him, what he wants, and yet, he's still willing to try and be "manly" for the sake of his parents. He attempts soccer, but is ultimately beat up by the other boys on the team. Ludo, at times like these, fantasizes about living in a dream world with the his favorite toys, flying through the blue sky over the pink houses he would love to live in.
The acting by Ecoffey and Laroque is incredibly good, as are the dialogue and interactions from Berliner's screenplay. The fights and arguments they have over Ludo's problem, and they way they go about dealing with the situation, is intense and realistic; at the same time, the characters are given full development. Berliner's direction is straightforward--there isn't a lot of intricate camera work, and much of it appears to have been shot with a handheld to give many of the scenes a visceral quality unusual to films of this kind.
Ma vie en rose is, perhaps, a little to light. There are funny moments here, and there should be; often, though, Berliner seems to avoid a certain amount heaviness that might have been appropriate for such a sobering subject matter. But I can also see how this avoidance might have a definite point--the film is not really about cross dressing, or even what becomes of Ludo in the long run. This is a film about accepting diversity, and realizing the innate and different qualities that some people have. I hold that Berliner didn't quite tap into this story's full potential, but the final product is still a film that presents its themes in a way that even skeptics might embrace.
*** out of **** (7/10, B)
Visit FILM PSYCHOSIS at http://www.pyramid.net/natesmovies
Nathaniel R. Atcheson
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Malta finance minister faces money-laundering probe
by EUobserverMalta's finance minister, Edward Scicluna, is to face a criminal inquiry on his role in the sale of three Maltese hospitals, a local magistrate has ruled. The affair comes after other senior government figures recently resigned over alleged links to the murder of a journalist in 2017. "A eurozone finance minister under money laundering investigations is unbearable" and Scicluna ought to "step down," Sven Giegold, a German Green MEP, said.


Central to machine learning is our ability to relate how a learning algorithm fares on a sample to its performance on unseen instances. This is called generalization.
In this post, I will describe a purely algorithmic approach to generalization. The property that makes this possible is stability. An algorithm is stable, intuitively speaking, if its output doesn’t change much if we perturb the input sample in a single point. We will see that this property by itself is necessary and sufficient for generalization.
Example: Stability of the Perceptron algorithm
Before we jump into the formal details, let’s consider a simple example of a stable algorithm: The Perceptron, aka stochastic gradient descent for learning linear separators! The algorithm aims to separate two classes of points (here circles and triangles) with a linear separator. The algorithm starts with an arbitrary hyperplane. It then repeatedly selects a single example from its input set and updates its hyperplane using the gradient of a certain loss function on the chosen example. How bad might the algorithm screw up if we move around a single example? Let’s find out.
Step 1/30. Click to advance.
The animation shows two runs of the Perceptron algorithm for learning a linear separator on two data sets that differ in the one point marked green in one data set and purple in the other. The perturbation is indicated by an arrow. The shaded green region shows the difference in the resulting two hyperplanes after some number of steps.
As we can see by clicking impatiently through the example, the algorithm seems pretty stable. Even if we substantially move the first example it encounters, the hyperplane computed by the algorithm changes only slightly. Neat. (You can check out the code here.)
Empirical risk jargon
Let’s introduce some terminology to relate the behavior of an algorithm on a sample to its behavior on unseen instances. Imagine we have a sample $S=(z_1,\dots,z_n)$ drawn i.i.d. from some unknown distribution $D$. There’s a learning algorithm $A(S)$ that takes $S$ and produces some model (e.g., the hyperplane in the above picture). To quantify the quality of the model we crank out a loss function $\ell$ with the idea that $\ell(A(S), z)$ describes the loss of the model $A(S)$ on one instance $z$. The empirical risk or training error of the algorithm is defined as:
This captures the average loss of the algorithm on the sample on which it was trained. To quantify out-of-sample performance, we define the risk of the algorithm as:
The difference between risk and empirical risk $R - R_S$ is called generalization error. You will sometimes encounter that term as a synonym for risk, but I find that confusing. We already have a perfectly short and good name for the risk $R$. Always keep in mind the following tautology
Operationally, it states that if we manage to minimize empirical risk all that matters is generalization error.
A fundamental theorem of machine learning
I probably shouldn’t propose fundamental theorems for anything really. But if I had to, this would be the one I’d suggest for machine learning:
In expectation, generalization equals stability.
Somewhat more formally, we will encounter a natural measure of stability, denoted $\Delta$ such that the difference between risk and empirical risk in expectation equals $\Delta.$ Formally,
$\mathbb{E}[R - R_S] = \Delta$
Deferring the exact definition of $\Delta$ to the proof, let’s think about this for a second. What I find so remarkable about this theorem is that it turns a statistical problem into a purely algorithmic one: All we need for generalization is an algorithmic notion of robustness. Our algorithm’s output shouldn’t change much if perturb one of the data points. It’s almost like a sanity check. Had you coded up an algorithm and this wasn’t the case, you’d probably go look for a bug.
Proof
Consider two data sets of size $n$ drawn independently of each other: [ S = (z_1,\dots,z_n), \qquad S’=(z_1’,\dots,z_n’) ] The idea of taking such a ghost sample $S’$ is quite old and already arises in the context of symmetrization in empirical process theory. We’re going to couple these two samples in one point by defining [ S^i = (z_1,\dots,z_{i-1},z_i’,z_{i+1},\dots,z_n),\qquad i = 1,\dots, n. ] It’s certainly no coincidence that $S$ and $S^i$ differ in exactly one element. We’re going to use this in just a moment.
By definition, the expected empirical risk equals
Contrasting this to how the algorithm fares on unseen examples, we can rewrite the expected risk using our ghost sample as:
All expectations we encounter are over both $S$ and $S’$. By linearity of expectation, the difference between expected risk and expected empirical risk equals
It is tempting now to relate the two terms inside the expectation to the stability of the algorithm. We’re going to do exactly that using mathematics’ most trusted proof strategy: pattern matching. Indeed, since $z_i$ and $z_i’$ are exchangeable, we have
where $\delta_i$ is defined to make the second equality true:
Summing up $\Delta = (1/n)\sum_i \delta_i$, we have
The only thing left to do is to interpret the right hand side in terms of stability. Convince yourself that $\delta_i$ measures how differently the algorithm behaves on two data sets $S$ and $S’$ that differ in only one element.
Uniform stability
It can be difficult to analyze the expectation in the definition of $\Delta$ precisely. Fortunately, it is often enough to resolve the expectation by upper bounding it with suprema:
The supremum runs over all valid data sets differing in only one element and all valid sample points $z$. This stronger notion of stability called uniform stability goes back to a seminal paper by Bousquett and Elisseeff.
I should say that you can find the above proof in the essssential stability paper by Shalev-Shwartz, Shamir, Srebro and Sridharan here.
Concentration from stability
The theorem we saw shows that expected empirical risk equals risk up to a correction that involves the stability of the algorithm. Can we also show that empirical risk is close to its expectation with high probability? Interestingly, we can by appealing to stability once again. I won’t spell out the details, but we can use the method of bounded differences to obtain strong concentration bounds. To apply the method we need a bounded difference condition which is just another word for stability. So, we’re really killing two birds with one stone by using stability not only to show that the first moment of the empirical risk is correct but also that it concentrates. The only wrinkle is that, as far as I know, the weak stability notion expressed by $\Delta$ is not enough to get concentration, but uniform stability (for sufficiently small difference) will do.
Applications of stability
There is much more that stability can do for us. We’ve only scratched on the surface. Here are some of the many applications of stability.
-
Regularization implies stability. Specifically, the minimizer of the empirical risk subject to an $\ell_2$-penalty is uniformly stable.
-
Stochastic gradient descent is stable provided that we don’t make too many steps.
-
Differential privacy is nothing but a strong stability guarantee. Any result ever proved about differential privacy is fundamentally about stability.
-
Differential privacy in turn has applications to preventing overfitting in adaptive data analysis.
-
Stability also has many beautiful applications and connections in statistics. I strongly encourage you to read Bin Yu’s beautiful overview paper on the topic.
Looking ahead, I’ve got at least two more posts planned on this.
In my next post I will go into the stability of stochastic gradient descent in detail. We will see a simple argument to show that stochastic gradient descent is uniformly stable. I will then work towards applying these ideas to the area of deep learning. We will see that stability can help us explain why even huge models sometimes generalize well and how we can make them generalize even better.
In a second post I will reflect on stability as a paradigm for reliable machine learning. The focus will be on how ideas from stability can help avoid overfitting and false discovery.


set dialog pc fc bc oc th <numeric|n>
Sets color properties for dialog box widgets.
pc
prompt color fc
foreground text color bc
background color oc
outline color th
outline thickness n
numeric input only (optional)
th
is 1-5, a one-pixel border is drawn; if
it is 6 or more, a two-pixel border is drawn.
q dialog
refrence page for details on execution of the dialog box widgets.
set dialog 1 0 5 1 6 q dialog Hello World say result


This document is meant to capture the state of the discussion about modernising the tooling that supports the making of W3C standards.
Discussion is open to all. Pull requests are welcome, and the discussion takes place in the issues.
This is just informal work by an informal task force.
W3C is a heavily tooled organisation. We did Web tools long before they became ubiquitous and our tooling has earned us two decades of praise — which is probably more than can be said for any other part of the organisation.
But the Web has changed quite a fair bit since then. Today, tools abound. The Web is an application platform. Our users are happy using many third-party tools, and it is only natural that they will compare what they can find elsewhere to our offering, sometimes preferring other options.
This causes problems:
We need an energetic rethink of the W3C’s tooling in order to stay relevant to our users. That is what this document endeavours to provide.
I expect to proceed as follows:
While precise details about the manner in which our various tools could be improved were deliberately kept out of this document, there are nevertheless many things that people would like to see changed, improved, or added. As a result, the full list in the following sections is long, and it is easy to get one’s eyes off the ball.
This section provides information on the projects that have been deemed high priority. These are described at a high level, and resource estimates are provided for them. «First priority» projects are intended for immediate development, «Second priority» projects are expected to come in a second wave. Everything in this document not listed as part of those two categories is considered to be kept for later. Note that «later» is not a fancy word for «never», and people interested in jump-starting those should of course jump right to it. It simply means that they are not immediately planned for with the resources available for the execution of this plan.
Everything includes documentation and testing. All projects are expected to use continuous
development, which is to say that whenever something hits the master
branch it
is deployed into production.
The projects in this category include:
This is required for development and beta-testing purposes.
Estimate: Personal server will be used for testing, done.
The goal of this project is to develop a service that can integrate all of the information being produced as we work (as it happens) and expose it for querying. It is the foundational brick for the dashboard, the notifiers, and possibly other services.
Estimate: 1 month FTE.
A configurable dashboard exposing the information that a given user wants to have. This is necessary in order for people not to be lost anymore. This is intended to evolve towards a full-fledged control panel for our users, but in the first pass the primary goal is to make it work as a configurable information-access system.
Estimate: 1 month FTE.
This system plugs into the unified feed and send emails to specific targets for a filtered subset of events.
Estimate: At most a couple days’ work.
Same as the email notifier, but for IRC channels. Note that this could be demoted to lower priority.
Estimate: 2 weeks FTE
As more of our work transitions to GitHub, we need to maintain a backup of the information we have there. The unified feed already effectively backs up information from issues and the such, but the actual git content needs to be backed up as it changes.
Estimate: 1 week
Echidna needs to send the information that it processes to the unified feed.
Estimate: At most a few days’ work.
This project is already under way, as such it is not specifically part of the Modern Tooling effort. It is, however, important to have it available in time for some of projects currently listed in «Priority Two».
Estimate: 0 (already accounted for).
We already have an experimental installation of Discourse, but we want to move it to WebPlatform. This is essentially: reinstalling, exporting the data, redirecting.
Estimate: 0 (turns out it will already be done)
The manner in which groups manage their own pages today is appalling. The goal of this project is to provide common infrastructure for them to be able to start reporting on their work effectively. This has the added benefit that it can expose information from groups straight to the unified feed (and then in turn to the dashboard).
Estimate: 1 month FTE.
This is already in progress. It essentially requires some tweaking and then deployment at a decent URL. It should not have to block on things like donations; as soon as the content is good we can ship it, and then iterate as more information and functionality become available.
Estimate: 10 days FTE.
A general guide for the usage of GitHub, as well as guides for the tools listed in this category (including Echidna) need to be written.
Estimate: 2-3 weeks FTE.
The projects in this category include:
The goal of this project is to make the user interface for mailing lists more usable.
Estimate: 2-3 months FTE.
Our specification could suffer to make use of modern capabilities standardised across the board (rather than added in an ad hoc fashion here and there).
Estimate: 3 weeks FTE.
The ability to have live examples that can be experimented with directly in the specification would help make things much easier to understand for readers.
Estimate: 2 weeks FTE.
The current WebIDL checker works, but it should be integrated into Specberus.
Estimate: 1 week FTE.
A number of GitHub maintenance tasks are pretty repetitive and could be partially automated. Also, templates to set up repositories would help people get it right and not have to learn tricks from the lore.
Estimate: 3 weeks FTE.
Many people want to improve our specification styles, but «Big Bang» attempts to change them entirely have so far failed. The goal of this project is to make the styles open source in order to make it possible for people to contribute to gradual improvements.
Estimate: 2 weeks FTE.
Etherpads are very useful for collaboration, yet W3C does not offer one. As a result, people use pads all over the place. This project simply installs an instance of our own. The first step is to figure out which one is the best option.
Estimate: @@systeam (will be estimated later, ongoing discussion).
We regularly need to provide some degree of access to some trusted collaborators. The
primary use case is the Web Platform Tests system where we have external developers.
This could simply be no more than putting grumple
outside the firewall
and granting access to two or three people. This also needs a clear policy.
Estimate: @@ted (the most urgent item already done, may not require more).
There are multiple stakeholders with varying needs when it comes to tooling.
AC Reps represent W3C members within W3C, and, in a sense, W3C activities within their own companies.
Their requirements include tools that provide a good overview of their organization's activity in different sectors, their administrative duties, and legal aspects.
…
…
…
…
…
…
…
This section is a categorised but unprioritised list of tools and services that W3C should deploy, as well as ideas on how to manage integration with third-party systems.
The heart of what we produce is specifications, as a manifestation of consensus. These already have some tooling support but it can be both further and better integrated or documented.
Great progress has already been made thanks to the Echidna system that can publish Working Drafts in an automated manner, as often as needed. This can effectively make TR documents and Editor’s Drafts indistinguishable.
There are, however, still a number of exceptions to the documents that Echidna can publish, and a number of rough edges to the system itself and its documentation. It needs iterative improvements.
It will also need to expose a stream of notifications (as described further below) for the documents it publishes.
While the door needs to remain open for alternatives that our users may wish to avail themselves of, the expected default location for specifications (and any other W3C-related repository) should be GitHub, preferably under the w3c organisation. This has several implications.
We need to document the proper usage of GitHub for such work. Some of our users who are not from the Web development community can at times struggle with the site or with common conventions. Team resources need to be dedicated to supporting users of GitHub. A specific collaboration with GitHub may be considered if needed. NOTE: a repository has been created precisely to work on this aspect.
Better even than documentation, which is often ignored, a tool that enables the Team and the Chairs to set up new repositories correctly, within conventions, and given a few specific options would be most useful.
Groups regularly need to add new contributors to their repositories (or, on occasion, to remove them); which requires administrative powers. Sadly, the granularity of the ACL system there does not allow us to grant that power to non-Team participants, which in turn means that the Team needs to be called upon for everyday business. An interface to grant our users the ability to maintain a repository’s collaborators without involving the Team would be a time-saver. The ability to activate Travis without admin powers would also come in handy and save the Team some time.
 In such an event, we must have all the useful data at hand and, if possible, be able to exploit it elsewhere. Git certainly makes it easy to keep repository data — it only needs be cloned.
But GitHub also has a lot of useful information that isn’t in git: issues, discussions, etc. We also need to keep that around. For that, we need a GitHub backup tool. This would use git’s naturally distributed nature in conjunction with the ability to receive organisation-wide hooks (and use the API to grab everything) in order to store all the useful information. Ideally all work would happen under the w3c organisation but the tool ought to be flexible enough to account for there being work elsewhere.
The hook system should also be used so as to produce a stream of notifications that can later be integrated into the dashboard.
This also entails that both dev.w3
and dvcs.w3
should be phased
out. No new repository should be created there and no new user granted access. Projects
that are still active there should be moved (and redirected). Obviously the content
already published that no one is touching will likely need to stay there, but it should
essentially be a static, frozen archive of old work.
We regularly hear complaints about the usability of our specification styles. Several projects were started to radically improve them, but petered out.
At the same time, they cannot be changed radically overnight. Older specifications cannot be broken through style changes and we shouldn’t throw away the brand recognition that comes with the current style.
The solution is to open up the management of these styles and drive the project through largely small, incremental updates to the stylesheets. A repository for the styles should be created and we should start accepting pull requests. At first a clean-up of the current code ought to be carried out. Then, regular releases ought to be made based on contributions.
The Web is no longer a static medium that is essentially fluid print brought to the screen. Documents today can work with the user interactively. So far we have only very sporadically made use of these capabilities, when in fact they could greatly enhance the usage of our primary products.
A common library should be developed to provide basic functionality across all specifications. This would include:
Like the styling project, this can easily start small and humble, and progressively grow into a highly useful system thanks to contributions.
The new PubRules system (Specberus) is a welcome improvement in the toolbox. It still needs some UI fixes and should be moved to a location not intended to make it impossible to find, but overall it should soon be able to replace the previous instantiation.
We should, however, think beyond specification validation. As things stand today, it is extremely hard to get information out of our documents. Even when they are correct, they are all different. The RDF export is a very partial view and borderline unusable. The data that is extracted into W3C’s systems cannot be obtained, and is partial as well. Yet so much could be done with this information.
We need to progressively refine the components that make up a specification and to rethink them using modern HTML constructs for document semantics and metadata. Step by step we need to start unifying these constructs across the board (having tools produce them and enforcing them through PubRules). Document structure and metadata need to become eventually regular enough that TR can be used as an API.
We have quality specification production tools and most specifications today make use of them. It is worth thinking about how, as a common ecosystem, they can be improved.
One aspect in which they can be improved is to bring their source formats in line wherever it makes sense (and isn’t disruptive). The end goal here is that contributors to specifications who move between groups should as much as possible find themselves able to switch between tools as easily as possible.
This, naturally, should not be done at the cost of innovation in those tools, but it surely can be done for some of the common, well-understood aspects.
The Web platform is increasingly described by a large mesh of specifications that reference one another. Currently, this is done relatively poorly overall. There are several methods in use:
Ideally, all definitions from all specifications should be globally available. This would make it possible to simply reference them in a specification tool source format and get the correct link and reference handled. It would enable the generation of glossaries. (We urgently need to phase out the current one.) We could expose a searchable interface that would make it possible for people to find which specification defines what, and which make use of what concept or construct (something that would prove invaluable in coordination).
It is extremely common today to replace examples in documentation with live ones that can be edited and rendered using one of the many services that provide such functionality.
While it is probably not acceptable to inject code from a third-party service into our specifications, there exist reusable components that would enable examples in our specifications to become hackable. This would have tremendous value for developers trying to learn and understand the technology.
Specref is the database of bibliographical references that specifications rely upon. It has been through several iterations and is generally considered good, but it can be improved.
Currently managed by Tobie, it could be brought under W3C management.
It could use a front-end for adding resources and a few other niceties to integrate it better with the W3C tool suite (e.g., improving Marcos’ [bibliography generator](http://marcoscaceres.github.io/bib_entry_maker/)).
Some specification issues (that are not about the actual prose content) can sometimes exist for embarrassingly long periods of time before anyone notices. Sometimes they are noticed after a document is finalised. Or they are raised at the worst moment, all at once when the editor is busy doing something else.
Developers use continuous integration to make sure that there is a constant pressure towards quality rather than a last-minute rush — so should editors. There have been experiments around this (using Travis’ integration with GitHub); they should be expanded and systematised.
Ideally, an editor should be able to, at the click of a button, have the proper Travis integration (and dependencies) installed into the specification’s repository and deployed for immediate usage. This could even be made the default at repository creation if it is known that it will contain a specification.
Several different tools can be called upon for quality checking; since they can be used on their own they are listed separately below and in the «Developer Tools» section.
We have an existing WebIDL Checker. It needs to be integrated into the quality workflow (arguably into Specberus as well as into the linting options of specification tools), exist with guarantees of maintenance, documentation, and made easy to find.
We have existing tools (that almost no one knows about) that can read a specification and validate that its references (at least to W3C or IETF documents) are up to date with the latest versions of those documents: the references checker and the IETF references checker.
While specification production tools, by building atop SpecRef, have largely removed the need for these, some specifications are produced by hand and some have local bibliographies. They should be part of automated checking.
W3C actually exposes a Spell checker tool (that can work with HTML). It is unclear that this could be integrated into automated checking (given the number of justifiable exceptions) but it could perhaps be made more prominent (or, if found not to be useful, retired).
W3C currently offers an HTML Diff service which is sometimes used to see changes to documents.
It is a common request to find out what has changed between two versions of a specification. In fact, producing a diff seems slated to be part of the new errata management approach that the AB is investigating.
This should be made automatic, and possibly specialised. Right now the HTML diff tool will produce as output a complete document, which can make the differences hard to find (e.g. a paragraph change in the whole HTML specification). It can also include a lot of spurious differences. (For instance, if a section was added at the beginning, all the section numbers come out as changes.)
This tool could be specialised for specifications in such a way that ignorable differences would be ignored. Also, an affordance could be exposed in specifications offering to show a diff between the version being looked at and any other version of that document.
Specs depends on one another, but there is very little done to ensure these dependencies are kept in sync; they are expected to be reviewed at transitions, and sometimes the link checker will spot a dependency gone wrong, but a more systematic approach would allow for better coordination across groups and reduce the risks for «monkey patching».
A dependency tracker that would allow to visualise and report the dependencies between specs, e.g. in terms of WebIDL interfaces but also in terms of algorithms, would be terrific. Ideally, they would lead to much more granular dependencies — a spec usually depends on a few items of a given spec, not the whole thing; assessing dependencies at the right granularity would be helpful for streamlining transitions on the Recommendation track.
Supporting WYSIWYG editing for specifications could help improve collaboration and contributions from people who might know HTML but are not necessarily versed in the specific formalism of a given specification tool.
While such a tool would be interesting and valuable, it is a long and complex project to put together, and likely not a priority.
Perhaps the most common complaint about the W3C’s tooling setup, which is only made worse by spreading work across a broad set of external services, is that there are too many places at which to track things, often in very different ways.
In addition to tracking information, taking action within the system also involves remembering where different parts are. There are several pages listing services (e.g. the Member page, the AC page, the Editors’ page) but they can prove overwhelming, especially since they often have content that is out of date. They are also very generic: most users don’t need to know everything that they contain.
This leads to three high-level requirements for a modern system, from its users’ point of view:
This translates to a specific design for the various moving parts of the system.
There are many sources of data that can become involved in the dashboard. In order to keep them manageable, we need a specialised component that can provide a consistent interface to them.
This service is a relatively simple shell around various data streams. It can be
configured to poll a resource at regular intervals (e.g. retrieve and process an RSS
feed), or on the contrary to expose a hook for pushed information (e.g. we can set up
a GitHub hook calling it for all events in the w3c
organisation there).
Ideally we could also collect data from mailing lists, for instance to produce a feed of
browser vendors’ intents to implement/deprecate.
Each of its plugins knows how to obtain data and store it in a unified manner. They can easily be configured (e.g. to add RSS feeds, to receive GitHub notifications from other repositories).
This mass of data can then be returned to queries that essentially involve two filters: which feeds the user is interested in, and a date-time cut-off so that one can ask only for what has happened since one last visited.
Additionally, a WebSockets interface can be made available so that dashboard users can get notifications in real time in the UI.
The dashboard itself is nothing but a container of smaller widgets which can be configured, added, or removed by each user. In order to be fully generic, we need to ensure that it remains extremely simple both in its own functionality and in the interface it exposes to widgets.
Widgets can be used as part of an overview grid, or can take over the whole screen when they need more real estate.
It is very important that it be possible for independent contributors to develop widgets
separately, that can then become available through the dashboard (after W3C approval, we
can’t automatically deploy third-party code). Widgets can expect to run in insulated
iframe
s and to communicate with the dashboard to access whatever
information they need through messaging.
W3C’s own applications are expected to transition to being exposed as widgets. The general principle at work is that services should be made available as APIs, and exposed to users through widgets. With this in mind widgets can use a common stylesheet and common scripting libraries to help support greater coherence and fluidity in interaction.
Another tool that can plug into the unified feed is a notifier. Users can opt into being notified of various events by email (through, you guessed it, a dashboard widget). Likewise, IRC channels can be notified of specific events by a bot. The idea is that this is extensible: the unified feed provides the data in a usage-agnostic manner; tools then piggy-back on it.
The notifier simply receives the unified data feed, and for each event finds if there are people who want to be notified of it. If so, they get an email.
The notifier needs to be able to filter events based on labels. For instance, the I18N WG uses «I18N» labels on bugs on other groups’ bugs trackers in order to track horizontal reviews. Similar conventions could be supported by other groups.
Dom has built a tool (github-notify-ml) that can notify mailing lists when certain events happen on GitHub. It could be enhanced to make use of this system.
It would prove particularly useful if the notifier were able to filter events to match changes to specific sections of a specification (notably to help horizontal reviewers).
This section covers tools that are in common use for coordination and communication inside groups and the broader community.
IRC is relatively operational and it is highly programmable. Because of this, it would be hard to replace with other more modern solutions such as Slack or gitter. It is, however, often unknown to the younger generation or in fact more generally to people not strongly steeped in the open source culture of the past twenty years. As such, an improved Web interface would be desirable. (The current one is serviceable, but could do with some freshening.) One potential option here would be Shout. It is a client-server combo with a rich interface, and is entirely implemented in JS. Amongst its advantages are that it can remain connected to IRC even when you close your browser, it supports connecting as the same user through multiple channels at once, and it has a responsive layout that is well-suited to usage on a smartphone.
IRC logging could, however, be improved. RRSAgent
has its value for the
specific case of capturing minutes in a manner that is easily reused by other tools, but
as a general-purpose logger we can do better. Too many channels are simply not logged at
all — even though much work takes place over IRC! And when they are logged,
RRSAgent
logs are then extremely hard to find; lost in dated-space never to
be retrieved again.
A general-purpose channel logger bot need not be complicated. In my experience, people are satisfied with Krijn Hoetmer’s setup. Its limitations are largely that it requires getting agreement from Krijn in order to get something logged, and it wouldn’t scale to the many channels we would want to log. The RICG also uses a simple Drupal-based PHP setup to reference discussion, retrive to GitHub issue information, and for minute-taking.
A single service at which all chat logs can be located would therefore be needed. It does not require bells and whistles, but it needs to support continuous logging, finding channels, and search.
While the mailing list service itself is largely beyond reproach, the interface to our archives is now one of the more decried parts of our offering. While a number of the complaints may be exaggerated, it is certainly true that it could do with improvements in both style and usability.
A project that is commonly cited as a huge improvement over what existed previously is https://esdiscuss.org/. It is not perfect, and the source can probably not be reused as is. Its fundamental architecture is sound however: convert email to JSON and expose those for other services to build upon. Given the size of the W3C archive and its daily volume, this would not be a minor undertaking — it is likely better to test-drive the idea on a small set of lists.
People have also complained about the user experience of signing up to our lists. A user interface allowing people who have an account (either with us, or with a third-party service that we can authenticate against) to use that to subscribe directly (without the email ping-pong) and to immediately accept archival would help our community as well.
Forums have overtaken mailing lists in terms of popularity for online discussion. Groups would certainly benefit from being able to rely on those for at least some of their work.
This aspect is already covered by our Discourse installation, which is being moved to WebPlatform.
Etherpads are commonly used to take shared notes, which could be useful for minutes in some groups, but is also particularly useful during brainstorming sessions when a group of people wishes to collectively.
Because W3C does not provide its own pads, people routinely use those available from Mozilla or the MIT. This results in information being scattered far and wide.
There are numerous pad implementations, so deploying this is largely a case of picking one that we like. A good pad should support:
Bonus points if there is a way for the pad to tie into our user system such that people who join a pad to edit automatically have their names set up.
This section is more of an open question than anything else. Some teams use systems like Trello to organise their work, basically through collaborative todo lists. I am not aware of groups doing the same, but I would be interested in hearing about usage or interest.
Three major bug trackers are in use in W3C groups: Bugzilla, Tracker, and GitHub Issues.
Bugzilla is the most powerful and flexible of the three, but it is extremely slow, its interface is clunky, and automating it through external tools generally requires scraping its HTML output. (There does exist a way of enable XML-RPC for it... but, well, it’s XML-RPC.) It also likes to send email; a lot.
Tracker is the only option with IRC integration (through trackbot
) and it
also supports action items in addition to issues. It knows about our users, IRC nicks,
and working groups, which can prove useful. However its interface is also clunky and
setting up a new instance for a given project requires intervention.
GitHub issues are by far the easiest to use. They have nice conversational capabilities. However they’re external to W3C and they don’t know about groups and the such.
I am making the following perhaps radical recommendations:
If we cannot unify our issues handling, then at the very least the various services will need to be plugged into the Unified Feeds system so as to be visible in the dashboard.
Horizontal review groups have their own needs in terms of issue tracking. Richard makes a good description of it in issue #8. Ideally the tracking system ought to enable the automation of many of the complex steps they need to go through.
W3C Working Groups should maintain a page about what they do, what their documents are with what status, what their upcoming events of note are, how they can be interacted with, etc.
Currently that is usually done by the team contact and/or chair hand-editing a bunch of HTML documents in CVS. The information provided is completely different from group to group, and the layouts are all over the place. If you know how to find information with one group, you will be lost with another. What’s more, the editing process is painful enough that it is rarely done, and can rarely be automated. Stale information abounds (it is very common to find completely outdated charters for instance, or list of minutes that stop two years ago even though the group is active). Some groups have moved a fair part of their information elsewhere, sometimes their own site, sometimes a wiki. This is further compounded by the fact that most — but not all! — group pages are in dated space somewhere. There is simply no easy way to find them; at times even search engines get confused.
Group content should be entirely moved to a single, easily found location. For instance,
https://groups.w3.org/$GROUP_NAME
.
Group pages should be managed using simple but effective tools. CMSs are unlikely to provide a good match in terms of flexibility and automation. A static generator system such as Jekyll ought to be used. A common layout should be deployed across the board. Similar information should be presented in a similar fashion and at similar locations (both on screen and in URL space).
In addition to the functionality already provided by such tools (pages and blogs for news being typical), it ought to be relatively easy to write plugins to publish calendaring information as well.
Wikis are annoying. Idiosyncratic syntax, little to no notification, practically nothing in the way of actual collaboration (people might work on the same document but don’t really talk, certainly not in practice). W3C makes the problem worse by having uncountable different wikis spread out all over the place. It is already hard to find information in one wiki; when one has to remember which wiki it was in things go awry.
That said, wikis do have their die-hard lovers and they will likely remain in use. I recommend:
Chairs often need to maintain a scribe rotation. It is not the end of the world, but it is a little bit of extra manual work that can easily go wrong.
A scribe manager could possibly be built atop the W3C Data API that the systeam is working on (assuming it could list group participants). You could mark people as "never scribing", click someone’s name when they’ve scribed, have new participants be sent to the bottom of the list.
Even with a freshened up and more organised setup, making use of all our tools and the external tools they rely on can be challenging.
It is absolutely necessary that there exist clear and well-identified guidelines for operating with these tools. Ideally, short enough that people actually read and memorise them.
Where possible, we should provide template configurations (e.g. the typical GitHub repository for a specification) that can easily be reused.
Additionally, it would likely be useful to create training material for the tools. The Team would naturally be subjected to it, but all newcomers (and in fact anyone interested) would be able to use this as a resource to get up to speed quickly.
Having an automatically maintained map of the all the WebIDL interfaces that are developed across the Web platform would make it easier to navigate the organic structure of Working Groups / Community Groups / etc., and would let groups more easily discover ways that other interfaces deal with specific patterns.
Both PLH and Dom have early versions of such a tool.
We have a community of dedicated people who translate specifications so that they can be read in a language more convenient to some of our users (see for instance Veebi sisu juurdepääsetavussuunised (WCAG) 2.0).
Translation can be difficult to organise well, and it can be hard to collaborate on a translation, especially for non-technical users who can nevertheless contribute usefully to this effort.
It would be interesting to have tools that support easier translation of our specifications, such as side-by-side views and document views updated live as the code is changed (to make things easier on those who have limited HTML experience).
Developers use W3C technology a lot, and some of our services. Yet we make little use of this interaction in order to build a relationship that we badly need. There is currently a lost opportunity to turn these useful (and, in some cases, used) tools into goodwill and good feedback. We are probably not getting as many donations as we could from these.
We don’t offer an integrated view on the tools that we make available to developers. There is ongoing work in exposing this through a simple landing page. The W3C developer page aims to provide developers with a summary of all our open source tools and links to helpful resources. It is currently in development, and you can contribute to it in its Github repository.
You are very welcome to join the discussion about features, design and more in the developers repository’s issues.
The Link Checker is one of the more useful resources that W3C exposes, but it is woefully antiquated.
While not a top priority, it would be useful to rebuild it with modern technology and a modern interface. It should be relatively straightforward to make it a fair bit faster, if only by adding some caching.
These are solid tools and do not need much work. We should stop calling the new HTML validator «experimental» and we should retire anything to do with the old one. We can sprinkle a little bit of nice design on the output, and we could document some of the APIs better, but nothing radical beyond some cleanup. It would be nice to ensure that the validators are available as libraries (outside Java), for instance as Gulp/Grunt packages that can easily integrate with common build systems for Web applications.
It has been suggested that it would be valuable to rewrite these two validators in a language more likely to be reusable by Web developers, namely JavaScript. While this may be true, it can only be a long-term, low-priority objective.
Note: the source for the Markup validator is Validator.nu.
As in the previous section, this is good and operational. It could use being promoted more.
We currently do not provide A11Y checking as a service, and arguments have been made that this would be a bad idea as there are aspects that cannot be tested. However, there are projects appearing that are beginning to offer this service (e.g. Tenon). We should take the time to think about our strategy here.
The MobileOK checker is a potentially valuable tool, but it needs an update. Validating XHTML Basic 1.1 or ensuring that a page is under 20K might not work that well with many modern uses of mobile. (Testing a site that I know works well on today’s devices scored it 29%.)
W3C is currently working on a new, open source version of the Mobile Checker. It is expected to be released soon.
These tools are currently not top priorities for the developers landing page but will be considered as soon as possible.
While not strictly a tool in itself, the core w3.org
site is a big part of
what our users interact with, and improving it would help with many aspects of their work,
notably not driving them to third parties when there is no need to.
CVS makes using the core site inordinately painful. I for one avoid publishing anything
there unless I really have to; in several cases I have set up an .htaccess
proxy from a subdirectory just so I would never need to touch it again. I know others
have similar experiences.
The massive size of the site also causes issues of its own. For instance, the recent discussion on upgrading to HTTPS across the board revealed just how hard it is to evolve it.
The site cannot be moved to a more modern system wholesale, but likely it does not need to.
W3C invented conventions before conventions existed. In some cases, those became conventions only within W3C.
Overview.html
is one of those. The norm is index.html
. It
should become the norm on all new Web setups at W3C, and where possible
Overview.html
ought to be retired. It may seem like a small thing but it is
a regular annoyance.
Dated space, of course, needs to die. There are exactly seven people in the world who find it usable, six of whom are on the Team (the other one being DanC). It is maddening, distracting, confusing, and in violation of every single URL design best practice in use anywhere outside the Consortium’s walls.
Again, dormant content in dated space can stay there. But content that is in any way, manner, or form still in active use should never be in dated space. A non-exhaustive list of content that should never be allowed to reside in dated space includes:
Our testing infrastructure has become increasingly important. In general it is much more recent than the rest of our tools and so less in need of modernising. But the setup can nevertheless be improved.
The Web Platform Tests (WPT) system relies on a code-review engine known as Critic. It ties into GitHub pull requests and is much more powerful than GitHub’s built-in code review.
Most groups likely do not need Critic, but for more complex code such as that which is found in tests it is a very welcome improvement.
The current Critic instance is run by James Graham on his personal server. It may be much better to host it on W3C.
It may be worth investigating the use of Reviewable as a potential hosted replacement.
We have an existing system that allows people to run (the automated parts of) the test suite continuously, without human intervention. Right now it has only been adopted by a couple of browser vendors.
We should take this to the next level. We can integrate with SauceLabs (with whom we have a free account) and systematically run the entire test suite against the full set of browsers that they expose. This should allow us to gather very detailed statistics about which parts of the platform work where. It has the added advantage that it can help detect some broken tests.
Finding out how much of a given specification is covered by the test suite is a hard, manual, and error-prone process. It cannot be perfectly automated, but it can be improved.
This also involves figuring out how to identify that a given test is related to part of a specification.
These tasks are not trivial and highly heuristic, but there has been previous work. It needs to be assessed and integrated.
One ideal use case for this is to be able to obtain a list of tests that need to be reviewed when the specific section of a specification that they map is updated.
Once we have testing results for many implementations, we should publish them in a manner that is useful to developers. Such information is invaluable. The interface does not require much in terms of complexity.
Creating new tests can in some cases be painful and slow, which in turn causes people to make mistakes as they cut and paste. This is particularly true for reference tests, and for groups that (still) require a lot of test metadata.
Part of that can be automated so that the basics of a test’s required parts can be filled out based on templates. Richard has a more extensive discussion of this proposal.
The testing project involves close collaborations between parties that are not all on the Team, yet develop the major parts of the system. While the service should be run on W3C resources, it would not be efficient to gate deployment to Team members only.
It must be possible to enable SSH access to a select group of contributors so that they could help curate the testing services.
These are services that can be reused by other parts of the ecosystem.
Many tools and services will expose features that are user-dependent. It is not appropriate for those to implement their own user database duplicating W3C’s. It would also be a shame if they had to make use of third-party sign-on infrastructure (which was the case with Discourse).
Which exact solution is selected here is of relatively little importance, but it does need to support typical modern Web application authentication workflows. GitHub’s OAuth implementation may provide a good example.
It should also be possible to retrieve useful information about a user, such as their GitHub ID.
The various tools to be developed may commonly require search functionality. Given the spread of W3C’s content, this can quickly become required. For instance, an Etherpad service might request indexing for its pads (using its own ACL knowledge), a chat logging service might index the logs, etc.
One potential candidate, that can double as a JSON document store and therefore be usable for application data storage, is Elastic Search.
It is this plan’s considered opinion that users should be encouraged to experiment with external tools if and when they find shortcomings in ours. Having said that, for an external tool to be considered acceptable it needs to fulfil the following basic needs:
Additionally, the W3C has requirements in terms of persistence. We cannot require of an external service that it make a promise of persistence it may be unable to keep, but we need to have the means to obtain our data easily so as to persist it easily ourselves. This has the nice side property that it requires full data export and ownership.
The following people have provided useful input into this document.


U = Upper Layer clockwise D = Down Layer clockwise F = Front Layer clockwise B = Back Layer clockwise Ui = Upper Layer anti-clockwise Di= Down Layer anti-clockwise Fi = Front Layer anti-clockwise Bi = Back Layer anti-clockwise X = Rotate the entire cube clockwise on R (i.e. on the axis from the right of the cube) Y = Rotate the entire cube clockwise on D (i.e. on the axis from the bottom of the cube) Z = Rotate the entire cube clockwise on F (i.e. on the axis from the front of the cube) M = Turn the middle layer between the left and right sides towards you E = Turn the middle layer between the up and down sides away from you S = Turn the middle layer between the front and back sides clockwise
======= >>>>>>> d46c22f179c7fb79e6728af029f0070785a9cb06


Generate benchmark reports based on page-load times for your website.
Visit https://aklump.github.io/website_benchmark for full documentation.
cloudy pm-install aklump/website_benchmark
./bin/website_benchmark measure --note="Before upgrade to PHP 7"
results_dir
, if that's been set and created.You must have Cloudy installed on your system to install this package.
The installation script above will generate the following structure where .
is your repository root.
.
├── bin
│ ├── website_benchmark -> ../opt/website_benchmark/website_benchmark.sh
│ └── config
│ └── website_benchmark.yml
├── opt
│ ├── cloudy
│ └── aklump
│ └── website_benchmark
└── {public web root}
cloudy pm-update aklump/website_benchmark
Refer to the files for documentation about configuration options.
| Filename | Description | VCS |
|---|---|---|
| website_benchmark.yml | Configuration for the script. | yes |
./bin/website_benchmark
If you find this project useful... please consider making a donation.