[Wikitech-l] Tip for Sublime Text editors: DocBlockr plugin and conf for JSDuck
Hi,
If you're using Sublime Text as your text editor[1], I'd recommend checking out
the DocBlockr plugin[2]. It makes it easier to produce documentation comments.
It helps you through various features such as:
* Autocomplete various @-tags
* Auto-create blocks[3]
* Detect function params and property value types
* And lots more..
It avoids mistakes and speeds up the creation of conformant comments so that
Jenkins/JSDuck won't shout at you.
Though it provides all this by default, I recommend you fine tune it to your
liking
(and to the specifics of JSDuck).
To deal with the variety in how different projects write documentation comments,
it has various configuration options[4] (e.g. @return vs @returns, @var, vs
@property,
type {Boolean}, {boolean} or {bool} etc.). I've published my configuration on
GitHub.
It might be useful to you to get started[5].
You can install DocBlockr in Subllime the easy way using Package Control[6],
or check out the plugin page[2] for manual installation.
-- Krinkle
[1] http://www.sublimetext.com/
[2] https://github.com/spadgos/sublime-jsdocs
[3] Type /** followed by tab to insert the template, then tab trough
placeholders to fill them in
[4]
https://github.com/spadgos/sublime-jsdocs/blob/2.11.7/Base%20File.sublime-settings
[4]
https://github.com/Krinkle/dotfiles/blob/b2088da/hosts/KrinkleMac/SublimePreferences.json#L17-L23
[5] https://sublime.wbond.net/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tip for Sublime Text editors: DocBlockr plugin and conf for JSDuck
On 2013-11-19 3:35 AM, Krinkle wrote:
Though it provides all this by default, I recommend you fine tune it to your
liking
(and to the specifics of JSDuck).
To deal with the variety in how different projects write documentation
comments,
it has various configuration options[4] (e.g. @return vs @returns, @var, vs
@property,
type {Boolean}, {boolean} or {bool} etc.). I've published my configuration on
GitHub.
It might be useful to you to get started[5].
No per-project config we can put right into core?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Code-in update (was Re: Google Code-in starting NOW (important!))
GCI is moving fast. We need more mentors and tasks, especially for software development! See below. On 11/18/2013 09:04 AM, Quim Gil wrote: http://www.google-melange.com/gci/homepage/google/gci2013 https://www.mediawiki.org/wiki/Google_Code-In You can see all our open tasks at http://www.google-melange.com/gci/org/google/gci2013/wikimedia Here goes a first report. I will send more of these but not as verbose. After one day we have 77 tasks in total, from which * 2 have been closed as FIXED: PROVIDE CSS CLASS (HLIST) TO DEFINE HORIZONTAL LISTS IN MEDIAWIKI CORE http://www.google-melange.com/gci/task/view/google/gci2013/5772232571748352 TRIAGE (RETEST) ANY 10 OF MEDIAWIKI VECTOR SKIN (DEFAULT) BUG REPORTS http://www.google-melange.com/gci/task/view/google/gci2013/5884303300886528 * 3 have been marked NeedsReview by the students: MAKE SIMPLESEARCH PARAMETERS TO APIOPENSEARCH CONFIGURABLE http://www.google-melange.com/gci/task/view/google/gci2013/5903692930744320 See https://gerrit.wikimedia.org/r/#/c/96162/ FIX LOW RESOLUTION RSS/ATOM FEED ICON FOR SIDEBAR http://www.google-melange.com/gci/task/view/google/gci2013/5795046364282880 See https://gerrit.wikimedia.org/r/#/c/96197/ ADD A GO BACK TO TOP BOTTON TO KIWIX http://www.google-melange.com/gci/task/view/google/gci2013/5839120244932608 * 2 marked for review have been pushed back by the mentors: FILE PAGES SHOULD USE HIDPI 'SRCSET' ATTRIBUTE FOR THE MAIN IMAGE http://www.google-melange.com/gci/task/view/google/gci2013/6705304553127936 SUPPRESS NATIVE INVALID E-MAIL WARNING ON SPECIAL:CHANGEEMAIL http://www.google-melange.com/gci/task/view/google/gci2013/5315763447529472 We are missing more mentors and tasks, especially in the category of DEVELOPMENT. The program is called Code-in, right? It's not too late. Come on, step in! https://www.mediawiki.org/wiki/Google_Code-In#Become_a_Wikimedia_GCI_mentor These students will help you getting actual work done. If you are busy enough to create tasks in Google Melange just point Andre Klapper and me to the related bug reports and we will do that piece of work for you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tip for Sublime Text editors: DocBlockr plugin and conf for JSDuck
On Tue, Nov 19, 2013 at 3:35 AM, Krinkle krinklem...@gmail.com wrote: DocBlockr Nice. I hadn't know about Package Control either. thanks --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tip for Sublime Text editors: DocBlockr plugin and conf for JSDuck
Package Control is you friend. How else do you install a linter or syntax highlighting for a new language without touching a mouse? On Tue, Nov 19, 2013 at 2:42 PM, Tomasz Finc tf...@wikimedia.org wrote: On Tue, Nov 19, 2013 at 3:35 AM, Krinkle krinklem...@gmail.com wrote: DocBlockr Nice. I hadn't know about Package Control either. thanks --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Applying nofollow only to external links added in revisions that are still unpatrolled
On 11/18/2013 01:59 PM, Gabriel Wicke wrote:
On 11/18/2013 12:27 PM, Risker wrote:
To be honest, I suspect if the Google fellow said anything like this, it
was that they might ignore nofollow on Wikimedia wikis, but I'm pretty
certain that he didn't say Mediawiki wikis.
I remember being surprised too that it applied to all MediaWiki
installations rather than just Wikimedia sites. I have pinged him about it.
I now received an answer from my contact at Google:
Google will not follow rel=nofollow links, and not flow pagerank
through them. That includes Wiki{m,p}edia sources.
So the information I got at Wikimania was either not correct or the
result of a misunderstanding on my part. Another possibility is that
this detail of how pagerank works is considered too sensitive for
publication.
It should not be too hard to verify this independently by setting up a
fresh page with an unguessable URL and linking it from a wiki page with
rel=nofollow. If googlebot visits that page (or it turns up in search
results), then rel=nofollow was ignored.
Gabriel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Facebook Open Academy
https://www.facebook.com/OpenAcademyProgram I am having a call with them on Friday morning PST and I will ask them these questions. Let me know if you have further questions or you want to join the chat. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture RFC review meetings
On 11/14/2013 01:19 PM, Quim Gil wrote: Wednesday, November 20, 2013 at 10:00 PM UTC at #wikimedia-meetbot https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 This is in less than 24 hours. There are no RFCs scheduled yet. That is still the case. Seeing how the previous iterations went, perhaps the schedule could be defined by these priorities: # RFCs previously discussed with actions completed. # RFCs previously scheduled that were left out because of lack of time. # New RFCs pushed by their promoters. # RFCs called by the architects for a resolution. Up to you. Nobody has commented on this idea. Nobody has proposed a specific RFC for tomorrow either. Only two people have signed up in the wiki page. I will be there operating MeetBot. :) Actually I have another meeting at the same time. Even if I could cancel it, it would be good to know whether the meeting will be hosted -- and whether someone could volunteer operating the bot this time. It's easy. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Facebook Open Academy
On Tue, Nov 19, 2013 at 7:14 PM, Quim Gil q...@wikimedia.org wrote: I am having a call with them on Friday morning PST and I will ask them these questions. Let me know if you have further questions or you want to join the chat. I'm sure you've thought of most of these, but some obvious questions: - Would the students be using our existing code review infrastructure or is something Facebook specific required? - Would Facebook be the mentors for the program, with MediaWiki simply providing basic support? Or maybe each student would have a MediaWiki mentor as well as somebody from Facebook? - What is the syllabus for the class? What are the requirements for passing and getting college credit? - Do students work on multiple open source projects during the class? Or would they devote most of their effort to one project, and only contribute to others as an optional thing? - The document mentions teams. Are students put together in teams to work on stuff? If so how large are the teams, and how does this interact with the previous question? This is literally everything I could think of, so if a question seems inappropriate feel free to leave it out. Thanks in advance. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Comet
Thanks for responding, Aran, Tyler, and Daniel. I appreciate your thoughtful advice. I am planning to use SSE. It's for some slow server-side operations that typically take 1-3 minutes or so, where I want to give the user near-real-time updates on what's happening. I don't need full duplex or a long-term connection, and I don't want to make wiki admins install extra server software. I could just do it with Ajax polling, but I think SSE will give a more responsive feel. I have an early version of this working now, that watches a file and spools it out in an SSE event stream (by violently hijacking the ApiBase logic and seizing low-level control of the HTTP response - I'm sure it could be integrated into the output options in the Api class hierarchy if there's interest). This seems to work pretty well so far. For slow operations with side effects, I'm going to do it in two parts: client calls api.php to request the operation; it sends back a single SSE event containing a key, and goes on with its business, writing information about its progress to a file; client calls api.php a second time, using the key, to watch that file. This way it can robustly handle a bad connection or timeout by reconnecting without causing any unwanted side effects, like restarting the long operation. The stream of output could just as well go in memcache or the database as in a file, but for my project it makes more sense to use the file system, because some of it will come from redirecting the output of unix commands. LW From: Aran a...@organicdesign.co.nz Wouldn't WebSocket be the better choice for a full duplex channel? On 14/11/13 21:12, Lee Worden wrote: In the MW extension development I'm doing, I'm thinking of writing some operations that use [[Comet_(programming)]] to deliver continuous updates to the client, rather than the Ajax pattern of one request, one response. Has anyone messed with this? Any code I should crib from, or advice or cautionary tales? Also, if it develops into something useful, I could split it out for others to use. Thanks, LW From: Tyler Romeo tylerro...@gmail.com I have not messed with it personally, but I think it is a good idea. You should also know that the HTML5 standard has standardized the Comet model into server-sent events (SSE). [1] Mozilla also provides a nice tutorial on how to use it. [2] However, one big catch is that this is not currently implemented in Internet Explorer or mobile browsers. [3] So you'd have to have your own custom pure-JavaScript implementation for IE support. WebSocket, as another mentioned, is also an approach you could use. However, WebSockets are meant for full duplex communication, meaning the client is also talking back to the server, which may or may not be what you want. Also using WebSockets means the internals of what is sent over the socket and what it means is left to you to design, rather than being standardized. Not to mention the fact that you have to implement WebSockets in PHP or find a reliable library that will do it for you. And even then, WebSockets are only supported in IE 10 and later, so you're still a bit screwed in terms of backwards compatibility. [1] http://www.w3.org/TR/eventsource/ [2] https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events [3] http://caniuse.com/#feat=eventsource From: Daniel Friesen dan...@nadir-seen-fire.com Rather than natively using WebSockets you could use a higher-level library. There are two of these in existence, Socket.IO[1] and SockJS[2]. Socket.IO is the popular implementation. However when I looked into it I found SockJS to be the superior implementation IMHO. These libraries use WebSockets when available and fall back to a variety of other methods when WebSockets aren't available. So they support practically every browser. However you're probably going to have to give up on PHP. Neither Socket.IO nor SockJS have a PHP server implementation. The only thing that shows up for Socket.IO is Elephant.IO[3] which is a Socket.IO *client*. If you go down to raw WebSockets there is Ratchet[4]. However that brings up a number of issues that accumulate up to losing every single point you could possibly have to run it using PHP. Ratchet needs to spawn its own server. This means it needs a dedicated port, domain, or a reverse proxy in front of it. It also means that even though it's written in PHP you can no longer run it on any form of shared hosting. PHP is also not designed to run long running daemons. It can do it, but you will have to watch this very carefully and be prepared to fix any bugs that show up. You'd expect that since it's in PHP you at least have the one remaining advantage that you can directly interact with MediaWiki. However all of MediaWiki's code is synchronous. This means that if you directly use MW every time it needs to do something with the database, memcached, filesystem, other storage, or a slow MW code path your
[Wikitech-l] RFC: Configuration database 2
Hello, As discussed in the last RFC review meeting, I've put together a proposal for an on-wiki configuration scheme: https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2. Comments and feedback would be appreciated! I've also added this to the list for tomorrow's RFC review meeting. Thanks, -- Kunal Mehta (Legoktm) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Multimedia] Welcome, Aaron Arcos (volunteer!)
On 11/18/2013 06:38 PM, Rob Lanphier wrote: I'm thrilled to announce that Aaron Arcos has agreed to volunteer for the Wikimedia Foundation as a developer with our Multimedia team through May. Welcome. I look forward to working with you. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
