!ORfrUEFeWFcHAMLFLr:matrix.org

Federated Wiki

138 Members
General Federated Wiki Discussion18 Servers

Load older messages


Timestamp Message
20 Jan 2020
06:33:58@millysoose:matrix.orgmillysoose joined the room.
22 Jan 2020
05:16:41@Ward:matrix.orgWardI'm liking deno. http://found.ward.bay.wiki.org/deno-is-node-corrected.html
05:17:32@Ward:matrix.orgWard

Here is my first program, first.js

console.log(2+3, import.meta.main)
05:20:26@Ward:matrix.orgWard

I run it with deno first.js which prints 5 true. I'm less sure I like the standard format from deno fmt first.js.

console.log(2 + 3, import.meta.main);
16:30:17@dobbs:matrix.orgericI'm likely to miss our hangout today while CenturyLink upgrade my network.
16:46:16@Ward:matrix.orgWardWe'll think nice thoughts about you're future jitter-free participation.
17:39:00@Ward:matrix.orgWard

I'm looking for a simple server to select and run some tests at work. Pogo seems to be the deno framework that I'm wanting. Here is my first custom route.

server.router.get('/foo', () => 'bar')
17:41:47@Ward:matrix.orgWardYou may have noticed that I am easily impressed.
17:46:33@Ward:matrix.orgWardFederated wiki adds incremental and soon distributed full-text search. We'll video chat about this and other dev/user news starting in 15 minutes. https://hangouts.google.com/call/vh8qSgMVs-k-qOFdtwDAAAEI
19:03:08@mike_hales:matrix.orgmike_halesGood to be in the chat today :) Ward, remind me - what was your route to the Lineup Diagram page? The string/slug doesn't appear to be in my neighbourhood/server (federated.wiki).
23 Jan 2020
03:10:26@Ward:matrix.orgWard mike_hales: This is the design document we wrote for the hamburger menu, This document has a picture of the menu button to go into the web page footer. http://ward.asia.wiki.org/hamburger-menu.html.
03:12:15@Ward:matrix.orgWardHere is a bit of history going back to 1981. Wikipedia is clear that there is both a button (that resembles a hamburger) and a menu that appears when you click the button. https://en.wikipedia.org/wiki/Hamburger_button
03:14:45@Ward:matrix.orgWardThe actual menu that pops up depends on what plugin features are offered by the server hosting your site. I tried the hamburger button on federated.wiki and got a menu that looks like this.
03:14:52@Ward:matrix.orgWardimage.png
image.png
10:40:35@mike_hales:matrix.orgmike_hales Ward Thanku
14:24:37@Paul90:matrix.orgpaul90I currently don't think that the plugin pages should be included in the index for each wiki. Rather that there should be a single index of the plugin pages for each farm, or non-farm server. Currently not sure if index of plugin pages should then be included in the incremental search (the full text part of which is https://github.com/fedwiki/wiki-client/pull/259), maybe a development of the current search plugin is a better place.
14:25:47@Paul90:matrix.orgpaul90 * I currently don't think that the plugin pages should be included in the index for each wiki. Rather that there should be a single index of the plugin pages for each farm, or non-farm server. Currently not sure if index of plugin pages should then be included in the incremental search (the full text part of which is https://github.com/fedwiki/wiki-client/pull/259), maybe a development of the current search plugin is a better place.
14:30:33@Ward:matrix.orgWardGenerated pages such as search results are shown as translucent. This suggests that they aren't stored anywhere but that doesn't mean that they shouldn't be forked. We should be sure that once forked, they are easily deleted. Pages that are retrieved from locations other than the site of origin are given a halo where the color offers some additional explanation. These too can be forked.
14:30:49@Ward:matrix.orgWardimage.png
image.png
14:34:07@Ward:matrix.orgWardHovering over the flag should explain the page. For green halos it says what plugin the About page came from. Perhaps we should extend this to ghost pages where search results and hamburger menu pages would say this. This hover logic was an accommodation for the color blind.
20:09:05@ya:matrix.allmende.ioyalaThank you for this rich recapitulation of the logic behind what we see. Unfortunately I am unable to get that nice accessibility tooltip to show on my screen.
20:11:12@ya:matrix.allmende.ioyalaAn interesting oddity with ghost pages is also, that they are not reproduced from opening a lineup link, such as via http://mh.federated.wiki/view/welcome-visitors/view/selected-plugin-pages/view/lineup-diagram / http://fed.wiki.org/view/welcome-visitors/view/selected-plugin-pages/view/peer-activity , instead their slug is offered as a page title for a new page to be eventually created.
20:11:27@ya:matrix.allmende.ioyalaBildschirmfoto von 2020-01-23 21-10-12.png
Bildschirmfoto von 2020-01-23 21-10-12.png
24 Jan 2020
04:18:12@Ward:matrix.orgWardThis is a space holder in the browser's location bar which makes the back button work correctly.
25 Jan 2020
03:15:25@dobbs:matrix.orgeric@johnbywater:matrix.org, I'm a fan of @jessitron — she's consistently writing very accessible articles and talks with resilience engineering topics. Today she's posted a recommendation for event sourcing. Thought you'd appreciate it: https://blog.jessitron.com/2020/01/24/capturing-the-world-in-software/
04:54:03@Ward:matrix.orgWardI like the real-world tone of the article. I've tried several times to get my head around event sourcing but it has always seemed like a subtle change in perspective that is made practical by the huge memory and fast networks between our computers. You may think you want a screen that shows what you own but you really want a system that knows how you came to own it. I stumbled into financial computing looking for objects and had a leaning towards modeling portfolios since that is what our users wanted to see. We ended up with two datatypes, financial Instruments and Transactions against them. One held public information, the other private. All other views could be synthesized. Our life became a lot easier when we modeled (with objects) the machinery that constructed positions from Transactions and then could answer a variety of questions about how that bit of work went. I've told the story often enough that others have repeated it. http://www.exampler.com/old-blog/2004/08/11/index.html
04:55:09@Ward:matrix.orgWard * I like the real-world tone of the article. I've tried several times to get my head around event sourcing but it has always seemed like a subtle change in perspective that is made practical by the huge memory and fast networks between our computers. You may think you want a screen that shows what you own but you really want a system that knows how you came to own it. I stumbled into financial computing looking for objects and had a leaning towards modeling portfolios since that is what our users wanted to see. We ended up with two datatypes, financial Instruments and Transactions against them. One held public information, the other private. All other views could be synthesized. Our life became a lot easier when we modeled (with objects) the machinery that constructed positions from Transactions and then could answer a variety of questions about how that bit of work went. I've told the story often enough that others have repeated it. http://www.exampler.com/old-blog/2004/08/11/index.html
08:30:10@chrisgebhardt:matrix.orgChris GebhardtMy proposed software architecture is similar to event sourcing, in the sense that software always builds the local current state based on asynchronously received statements about the real world. (Multi-sourced appends to the shared graph of immutable data entities..) However, it completely throws out objects and events upon them. These are replaced simply by strong typing and semantics within the data itself. There is no authoritative application code, just contracts specifying how semantic graph data may be used for different interactions among parties / components. Provenance and access control are cryptographic. To user space, there are no artificial boundaries like apps or networks or clients vs servers. There is just the local trusted subset of global graph data of interest. BYOC. (code)
14:50:15@Ward:matrix.orgWard Chris Gebhardt: Yes. This sounds attractive though I am personally still in awe of the complexity of the trade-off space. I read an interesting piece once discussing design decisions in Kafka. It started by asking how, on modern hardware, anything will persist. This lead to a discussion of how disk manufactures have accepted the responsibility of managing rotational latency and presenting their read-write resources through buffer management logic private to the device. And, they conclude that the manufacturer of the devices you will use are optimizing for sequential read access. I don't work at this level of abstraction but I have once and respect how these decisions have oversized impact on architecture. Then, after maybe three or four, or maybe ten more layers of abstraction we put something in front of the user that is expected to work.
14:53:37@Ward:matrix.orgWardHere is an interesting reflection on the evolution of streaming solutions from a Kafka insider that came my way via Neo4j's Michael Hunger. I loved the perspective though it is "just" talking about enterprise computing. https://overcast.fm/podcasts/episode_card/345590266365157?t=0

There are no newer messages yet.


Back to Room List