-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathapi-hackernews-node.postman_collection.json
463 lines (463 loc) · 71 KB
/
api-hackernews-node.postman_collection.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
{
"info": {
"_postman_id": "70a00f9e-544e-4795-b6f6-657d8fe8a265",
"name": "api-hackernews-node",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"item": [
{
"name": "users",
"item": [
{
"name": "Get all users",
"request": {
"auth": {
"type": "bearer",
"bearer": [
{
"key": "token",
"value": "{{TOKEN}}",
"type": "string"
}
]
},
"method": "GET",
"header": [],
"url": {
"raw": "{{HOST}}/users",
"host": [
"{{HOST}}"
],
"path": [
"users"
]
}
},
"response": []
},
{
"name": "Create user",
"request": {
"method": "POST",
"header": [],
"body": {
"mode": "raw",
"raw": "{\r\n\t\"email\": \"ediddhhdvofdfn@gmail.com\",\r\n\t\"password\": \"1234abcd\"\r\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{HOST}}/users",
"host": [
"{{HOST}}"
],
"path": [
"users"
]
}
},
"response": []
},
{
"name": "Delete user by id",
"request": {
"auth": {
"type": "bearer",
"bearer": [
{
"key": "token",
"value": "{{TOKEN}}",
"type": "string"
}
]
},
"method": "DELETE",
"header": [],
"url": {
"raw": "{{HOST}}/users/:id",
"host": [
"{{HOST}}"
],
"path": [
"users",
":id"
],
"variable": [
{
"key": "id",
"value": "fa7f88c2-3d8f-4fb4-b236-cae4ac73b8d4"
}
]
}
},
"response": []
}
]
},
{
"name": "posts",
"item": [
{
"name": "Get all posts",
"request": {
"method": "GET",
"header": [],
"url": {
"raw": "{{HOST}}/posts",
"host": [
"{{HOST}}"
],
"path": [
"posts"
],
"query": [
{
"key": "author",
"value": "TruthWillHurt",
"disabled": true
},
{
"key": "tag",
"value": "story",
"disabled": true
},
{
"key": "title",
"value": "Ask HN: Is your Kubernetes production-grade?",
"disabled": true
},
{
"key": "month",
"value": "April",
"disabled": true
}
]
}
},
"response": []
},
{
"name": "Get all posts by page",
"request": {
"method": "GET",
"header": [],
"url": {
"raw": "{{HOST}}/posts/page/:nroPage",
"host": [
"{{HOST}}"
],
"path": [
"posts",
"page",
":nroPage"
],
"query": [
{
"key": "author",
"value": "TruthWillHurt",
"disabled": true
},
{
"key": "tag",
"value": "story",
"disabled": true
},
{
"key": "title",
"value": "Ask HN: Is your Kubernetes production-grade?",
"disabled": true
},
{
"key": "month",
"value": "April",
"disabled": true
}
],
"variable": [
{
"key": "nroPage",
"value": "1"
}
]
}
},
"response": []
},
{
"name": "Refrest posts",
"request": {
"method": "POST",
"header": [],
"url": {
"raw": "{{HOST}}/posts/refresh",
"host": [
"{{HOST}}"
],
"path": [
"posts",
"refresh"
]
}
},
"response": []
},
{
"name": "Delete post by id",
"request": {
"method": "DELETE",
"header": [],
"url": {
"raw": "{{HOST}}/posts/:id",
"host": [
"{{HOST}}"
],
"path": [
"posts",
":id"
],
"variable": [
{
"key": "id",
"value": "d53dbd89-2d9d-4126-8073-d767ecae9ca0"
}
]
}
},
"response": []
}
],
"auth": {
"type": "bearer",
"bearer": [
{
"key": "token",
"value": "{{TOKEN}}",
"type": "string"
}
]
},
"event": [
{
"listen": "prerequest",
"script": {
"type": "text/javascript",
"exec": [
""
]
}
},
{
"listen": "test",
"script": {
"type": "text/javascript",
"exec": [
""
]
}
}
]
},
{
"name": "Login",
"event": [
{
"listen": "test",
"script": {
"exec": [
" pm.collectionVariables.set(\"TOKEN\", pm.response.json().accessToken)"
],
"type": "text/javascript"
}
}
],
"request": {
"method": "POST",
"header": [],
"body": {
"mode": "raw",
"raw": "{\r\n\t\"email\": \"ediddhhdvofdfn@gmail.com\",\r\n\t\"password\": \"1234abcd\"\r\n}",
"options": {
"raw": {
"language": "json"
}
}
},
"url": {
"raw": "{{HOST}}/auth",
"host": [
"{{HOST}}"
],
"path": [
"auth"
]
}
},
"response": []
},
{
"name": "Get all hacker news posts about node",
"request": {
"method": "GET",
"header": [],
"url": {
"raw": "https://hn.algolia.com/api/v1/search_by_date?query=nodejs",
"protocol": "https",
"host": [
"hn",
"algolia",
"com"
],
"path": [
"api",
"v1",
"search_by_date"
],
"query": [
{
"key": "query",
"value": "nodejs"
}
]
}
},
"response": [
{
"name": "[HN] - Get all posts about Node.js",
"originalRequest": {
"method": "GET",
"header": [],
"url": {
"raw": "https://hn.algolia.com/api/v1/search_by_date?query=nodejs",
"protocol": "https",
"host": [
"hn",
"algolia",
"com"
],
"path": [
"api",
"v1",
"search_by_date"
],
"query": [
{
"key": "query",
"value": "nodejs"
}
]
}
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "json",
"header": [
{
"key": "Date",
"value": "Wed, 27 Apr 2022 04:25:57 GMT"
},
{
"key": "Content-Type",
"value": "application/json; charset=utf-8"
},
{
"key": "Transfer-Encoding",
"value": "chunked"
},
{
"key": "Connection",
"value": "keep-alive"
},
{
"key": "ETag",
"value": "W/\"0e2b4190a83628f4d75d115e2e4113f6\""
},
{
"key": "Cache-Control",
"value": "max-age=0, private, must-revalidate"
},
{
"key": "X-Request-Id",
"value": "85bbb7dd-7383-4d42-bbf6-dd5b377af1c7"
},
{
"key": "X-Runtime",
"value": "0.042562"
},
{
"key": "Access-Control-Allow-Origin",
"value": "*"
},
{
"key": "Access-Control-Allow-Methods",
"value": "GET, PUT, DELETE, POST, OPTIONS"
},
{
"key": "Access-Control-Allow-Headers",
"value": "x-algolia-application-id, connection, origin, x-algolia-api-key, content-type, content-length, x-algolia-signature, x-algolia-usertoken, x-algolia-tagfilters, DNT, X-Mx-ReqToken, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Authorization, Accept"
},
{
"key": "Access-Control-Allow-Credentials",
"value": "false"
},
{
"key": "CF-Cache-Status",
"value": "DYNAMIC"
},
{
"key": "Expect-CT",
"value": "max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""
},
{
"key": "Strict-Transport-Security",
"value": "max-age=31536000; includeSubDomains; preload"
},
{
"key": "Server",
"value": "cloudflare"
},
{
"key": "CF-RAY",
"value": "7024cc167bdd9af5-MIA"
},
{
"key": "Content-Encoding",
"value": "br"
}
],
"cookie": [],
"body": "{\n \"hits\": [\n {\n \"created_at\": \"2022-04-27T02:43:54.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"tintedfireglass\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Node js has ridiculously large dependancy trees. There is is this joke that a hello world program in NodeJS is only complete when it has 200 dependancies. If one of those many npm modules has a backdoor/vulnerability then you are screwed which is not the case for other languages.\",\n \"num_comments\": null,\n \"story_id\": 31152148,\n \"story_title\": \"Ask HN: Why is Node.js more susceptible to supply chain attacks than e.g. PHP?\",\n \"story_url\": null,\n \"parent_id\": 31152148,\n \"created_at_i\": 1651027434,\n \"_tags\": [\n \"comment\",\n \"author_tintedfireglass\",\n \"story_31152148\"\n ],\n \"objectID\": \"31175677\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"tintedfireglass\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"<em>Node js</em> has ridiculously large dependancy trees. There is is this joke that a hello world program in <em>NodeJS</em> is only complete when it has 200 dependancies. If one of those many npm modules has a backdoor/vulnerability then you are screwed which is not the case for other languages.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Ask HN: Why is Node.js more susceptible to supply chain attacks than e.g. PHP?\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-27T01:39:54.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"xyzzy_plugh\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"> The failures should be relatively rare; when I say relatively I mean on the level of natural node failure.<p>And exactly how rare do you believe this to be?<p>In my experience, node failures at scale of hundreds to thousands of nodes are monthly to weekly, if not daily. Generally speaking, stability is a normal distribution. Young, new instances experience similar failure rates as old instances. If you have any sort of maximum node lifetime (for example, a week) or scale dynamically on a daily basis then you'll see a lot of failures.\",\n \"num_comments\": null,\n \"story_id\": 31170370,\n \"story_title\": \"Slack’s Incident on 2-22-22\",\n \"story_url\": \"https://slack.engineering/slacks-incident-on-2-22-22/\",\n \"parent_id\": 31174232,\n \"created_at_i\": 1651023594,\n \"_tags\": [\n \"comment\",\n \"author_xyzzy_plugh\",\n \"story_31170370\"\n ],\n \"objectID\": \"31175273\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"xyzzy_plugh\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"> The failures should be relatively rare; when I say relatively I mean on the level of natural node failure.<p>And exactly how rare do you believe this to be?<p>In my experience, node failures at scale of hundreds to thousands of <em>nodes</em> are monthly to weekly, if not daily. Generally speaking, stability is a normal distribution. Young, new instances experience similar failure rates as old instances. If you have any sort of maximum node lifetime (for example, a week) or scale dynamically on a daily basis then you'll see a lot of failures.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Slack’s Incident on 2-22-22\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://slack.engineering/slacks-incident-on-2-22-22/\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-27T01:39:44.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"nodesocket\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"I think they are covering their tracks and removing the bans, shadow bans, and censorship before Musk takes over and revealed it.\",\n \"num_comments\": null,\n \"story_id\": 31175111,\n \"story_title\": \"Twitter follower counts over the past 24-48 hours\",\n \"story_url\": \"https://twitter.com/TyCardon/status/1519067389110853633\",\n \"parent_id\": 31175111,\n \"created_at_i\": 1651023584,\n \"_tags\": [\n \"comment\",\n \"author_nodesocket\",\n \"story_31175111\"\n ],\n \"objectID\": \"31175272\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"<em>nodes</em>ocket\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"comment_text\": {\n \"value\": \"I think they are covering their tracks and removing the bans, shadow bans, and censorship before Musk takes over and revealed it.\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_title\": {\n \"value\": \"Twitter follower counts over the past 24-48 hours\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://twitter.com/TyCardon/status/1519067389110853633\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-27T01:03:04.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"smoldesu\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"> Our chattering class claims Musk is a supervillain. The truth is simpler: He wants free speech. They don't.<p>I say this as someone with middling thoughts on the guy: Elon Musk is not doing this to promote freedom.<p>Twitter is not a free system. It fundamentally cannot be free: even when owned and operated by a single majority stake, running the site will consistently be at-odds with the ideals of free speech and privacy. There's always a new lowest-common-denominator to filter, another extremist voice to cancel or another objectionable take to demonize. The internet is always this race to the bottom, and platforms at Twitter's scale simply can't host <i>everyone</i>. It's simply not going to happen. Elon can talk a big game, but I remain adamant that there is no way to keep Twitter "free" as in speech. Especially so if the current monetization scheme is still around.<p>There <i>are</i> free Twitter alternatives out there; Mastodon, Pleroma and Misskey have solved this by absolving the responsibility of moderation from a centralized party, and putting it into the hands of multiple federated site owners. This gets much closer to the idyllic world of free speech. There is no mob mentality, centralized authority or "right way" of doing things, just a few hundred nodes that all need to learn to live with each other. It works, too: it really is a win-win situation for everyone involved. It refutes the idea that microblogging can never be free, and makes Twitter look fairly silly in comparison.<p>So, I don't really care. Let Musk own Twitter, it's a private company and now he bought it. Anyone thinking that Twitter was some invulnerable public asset deserved to be bought and traded like that, anyways.<p>And for anyone who holds out hope that Musk can save Twitter, I'd love to talk about this in 3-6 months when nothing has changed except the MAU slowly declining.\",\n \"num_comments\": null,\n \"story_id\": 31174956,\n \"story_title\": \"Elon Conquers the Twitterverse\",\n \"story_url\": \"https://bariweiss.substack.com/p/elon-conquers-the-twitterverse\",\n \"parent_id\": 31174956,\n \"created_at_i\": 1651021384,\n \"_tags\": [\n \"comment\",\n \"author_smoldesu\",\n \"story_31174956\"\n ],\n \"objectID\": \"31175062\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"smoldesu\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"> Our chattering class claims Musk is a supervillain. The truth is simpler: He wants free speech. They don't.<p>I say this as someone with middling thoughts on the guy: Elon Musk is not doing this to promote freedom.<p>Twitter is not a free system. It fundamentally cannot be free: even when owned and operated by a single majority stake, running the site will consistently be at-odds with the ideals of free speech and privacy. There's always a new lowest-common-denominator to filter, another extremist voice to cancel or another objectionable take to demonize. The internet is always this race to the bottom, and platforms at Twitter's scale simply can't host <i>everyone</i>. It's simply not going to happen. Elon can talk a big game, but I remain adamant that there is no way to keep Twitter "free" as in speech. Especially so if the current monetization scheme is still around.<p>There <i>are</i> free Twitter alternatives out there; Mastodon, Pleroma and Misskey have solved this by absolving the responsibility of moderation from a centralized party, and putting it into the hands of multiple federated site owners. This gets much closer to the idyllic world of free speech. There is no mob mentality, centralized authority or "right way" of doing things, just a few hundred <em>nodes</em> that all need to learn to live with each other. It works, too: it really is a win-win situation for everyone involved. It refutes the idea that microblogging can never be free, and makes Twitter look fairly silly in comparison.<p>So, I don't really care. Let Musk own Twitter, it's a private company and now he bought it. Anyone thinking that Twitter was some invulnerable public asset deserved to be bought and traded like that, anyways.<p>And for anyone who holds out hope that Musk can save Twitter, I'd love to talk about this in 3-6 months when nothing has changed except the MAU slowly declining.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Elon Conquers the Twitterverse\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://bariweiss.substack.com/p/elon-conquers-the-twitterverse\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T23:44:02.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"spiralx\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Looks interesting, and I like the analysis of JQ's model in order to compare and contrast it with ZQ. It reminds me somewhat of the difference between XPath 1 to XPath 2 - the former worked great if you were selecting stuff and using the built-in functions to do some simple transformations but if you tried to go further it was a hot mess of incompatible types each with their own constraints and quirks. In XPath 2 they completely revised the data model and type system, making everything an atomic value, node or a sequence of values and/or nodes, allowing types to be queried and operated on, and added a ton of useful built-in functions and operators, making impossible queries in XPath 1 possible.<p><a href=\\\"https://docs.microsoft.com/en-us/archive/msdn-magazine/2003/january/the-xml-files-introducing-xpath-2-0\\\" rel=\\\"nofollow\\\">https://docs.microsoft.com/en-us/archive/msdn-magazine/2003/...</a><p>Anyway, I've installed ZQ and will look to use it, even my simple usage of JQ had already led to thoughts of writing my own, better version :)<p>Quick bug report: On the Aggregate Functions page the link to _countdistinct_ goes to the page for _count_, and there actually isn't a page at <a href=\\\"https://zed.brimdata.io/docs/language/aggregates/countdistinct/\\\" rel=\\\"nofollow\\\">https://zed.brimdata.io/docs/language/aggregates/countdistin...</a>.\",\n \"num_comments\": null,\n \"story_id\": 31166956,\n \"story_title\": \"Zq: An easier and faster alternative to jq\",\n \"story_url\": \"https://www.brimdata.io/blog/introducing-zq/\",\n \"parent_id\": 31166956,\n \"created_at_i\": 1651016642,\n \"_tags\": [\n \"comment\",\n \"author_spiralx\",\n \"story_31166956\"\n ],\n \"objectID\": \"31174559\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"spiralx\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Looks interesting, and I like the analysis of JQ's model in order to compare and contrast it with ZQ. It reminds me somewhat of the difference between XPath 1 to XPath 2 - the former worked great if you were selecting stuff and using the built-in functions to do some simple transformations but if you tried to go further it was a hot mess of incompatible types each with their own constraints and quirks. In XPath 2 they completely revised the data model and type system, making everything an atomic value, node or a sequence of values and/or <em>nodes</em>, allowing types to be queried and operated on, and added a ton of useful built-in functions and operators, making impossible queries in XPath 1 possible.<p><a href=\\\"https://docs.microsoft.com/en-us/archive/msdn-magazine/2003/january/the-xml-files-introducing-xpath-2-0\\\" rel=\\\"nofollow\\\">https://docs.microsoft.com/en-us/archive/msdn-magazine/2003/...</a><p>Anyway, I've installed ZQ and will look to use it, even my simple usage of JQ had already led to thoughts of writing my own, better version :)<p>Quick bug report: On the Aggregate Functions page the link to _countdistinct_ goes to the page for _count_, and there actually isn't a page at <a href=\\\"https://zed.brimdata.io/docs/language/aggregates/countdistinct/\\\" rel=\\\"nofollow\\\">https://zed.brimdata.io/docs/language/aggregates/countdistin...</a>.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Zq: An easier and faster alternative to jq\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.brimdata.io/blog/introducing-zq/\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T23:29:07.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"eliaspro\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Quoting the Consul docs [1]:<p>"Note that DNS is limited in size per request, even when performing DNS TCP queries.<p>For services having many instances (more than 500), it might not be possible to retrieve the complete list of instances for the service.<p>When DNS SRV response are sent, order is randomized, but weights are not taken into account. In the case of truncation different clients using weighted SRV responses will have partial and inconsistent views of instances weights so the request distribution could be skewed from the intended weights. In that case, it is recommended to use the HTTP API to retrieve the list of nodes."<p>[1] <a href=\\\"https://www.consul.io/docs/discovery/dns#service-lookups\\\" rel=\\\"nofollow\\\">https://www.consul.io/docs/discovery/dns#service-lookups</a>\",\n \"num_comments\": null,\n \"story_id\": 31170280,\n \"story_title\": \"Show HN: Caddy v2.5.0\",\n \"story_url\": \"https://github.com/caddyserver/caddy/releases/tag/v2.5.0\",\n \"parent_id\": 31173136,\n \"created_at_i\": 1651015747,\n \"_tags\": [\n \"comment\",\n \"author_eliaspro\",\n \"story_31170280\"\n ],\n \"objectID\": \"31174451\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"eliaspro\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Quoting the Consul docs [1]:<p>"Note that DNS is limited in size per request, even when performing DNS TCP queries.<p>For services having many instances (more than 500), it might not be possible to retrieve the complete list of instances for the service.<p>When DNS SRV response are sent, order is randomized, but weights are not taken into account. In the case of truncation different clients using weighted SRV responses will have partial and inconsistent views of instances weights so the request distribution could be skewed from the intended weights. In that case, it is recommended to use the HTTP API to retrieve the list of <em>nodes</em>."<p>[1] <a href=\\\"https://www.consul.io/docs/discovery/dns#service-lookups\\\" rel=\\\"nofollow\\\">https://www.consul.io/docs/discovery/dns#service-lookups</a>\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Show HN: Caddy v2.5.0\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://github.com/caddyserver/caddy/releases/tag/v2.5.0\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T23:02:03.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"dormando\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"I can say with certainty this isn't strictly true. The failures should be relatively rare; when I say relatively I mean on the level of natural node failure. If natural node failure isn't survivable without special systems to quickly replace downed nodes you don't actually have an N+1 redundancy system. Thus, the pools aren't large enough :) Or, in this case, if they really are failing this much then having them always lose their cache is a major reliability hole.<p>It's a subtle difference. I think many operators get used to node failures being extremely common when they don't necessarily have to be. I suspect the note on "if they come back on their own ensure they're flushed" meaning they have something unusual causing ephemeral failures. If that's just "cloud networking" there isn't much they can do but it's almost always fixable.\",\n \"num_comments\": null,\n \"story_id\": 31170370,\n \"story_title\": \"Slack’s Incident on 2-22-22\",\n \"story_url\": \"https://slack.engineering/slacks-incident-on-2-22-22/\",\n \"parent_id\": 31174107,\n \"created_at_i\": 1651014123,\n \"_tags\": [\n \"comment\",\n \"author_dormando\",\n \"story_31170370\"\n ],\n \"objectID\": \"31174232\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"dormando\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"I can say with certainty this isn't strictly true. The failures should be relatively rare; when I say relatively I mean on the level of natural node failure. If natural node failure isn't survivable without special systems to quickly replace downed <em>nodes</em> you don't actually have an N+1 redundancy system. Thus, the pools aren't large enough :) Or, in this case, if they really are failing this much then having them always lose their cache is a major reliability hole.<p>It's a subtle difference. I think many operators get used to node failures being extremely common when they don't necessarily have to be. I suspect the note on "if they come back on their own ensure they're flushed" meaning they have something unusual causing ephemeral failures. If that's just "cloud networking" there isn't much they can do but it's almost always fixable.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Slack’s Incident on 2-22-22\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://slack.engineering/slacks-incident-on-2-22-22/\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T22:16:08.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"sharpener\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Maybe someone familiar with the graph theory math can help me.<p>I don't understand why these properties aren't numerically accessible. Why is the estimation necessary?<p>E.g. Assume N nodes, and edges E can be created at random with redundancy (picking same edge e twice just keeps the prior edge) by picking pairs of points.<p>Assume N random edge picks are made, then the probability of e.g. a Hamiltonian cycle appearing in those N picks can be calculated.<p>(My quick back of envelope sketch says P(H-cycle) = N! / N^N , but please consult the expert literature.)<p>But one can also calculate the probability of a H-cycle given N+1 random picks, N+2 random picks, ... and that appears as \\n = P(H-cycle) * (1 + extra factors that account for increases in other edges not redundantly in the H-cycle)<p>(Again, my back of envelope sketch for N + 2 picks gives:\\n = P(H-cycle) * ( 1 + 2/(N-1)[N - 3 - 1/N]) , but please consult the expert literature.)<p>These probabilities would seem to tell a user that given a graph with N nodes and E edges, that if e.g. in the H-cycle case, E > N the user can get an explicit probability for the likelihood of a H-cycle being present.<p>Are there graph properties that prevent this approach being viable?\",\n \"num_comments\": null,\n \"story_id\": 31162576,\n \"story_title\": \"Elegant six-page proof reveals the emergence of random structure\",\n \"story_url\": \"https://www.quantamagazine.org/elegant-six-page-proof-reveals-the-emergence-of-random-structure-20220425/\",\n \"parent_id\": 31162576,\n \"created_at_i\": 1651011368,\n \"_tags\": [\n \"comment\",\n \"author_sharpener\",\n \"story_31162576\"\n ],\n \"objectID\": \"31173847\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"sharpener\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Maybe someone familiar with the graph theory math can help me.<p>I don't understand why these properties aren't numerically accessible. Why is the estimation necessary?<p>E.g. Assume N <em>nodes</em>, and edges E can be created at random with redundancy (picking same edge e twice just keeps the prior edge) by picking pairs of points.<p>Assume N random edge picks are made, then the probability of e.g. a Hamiltonian cycle appearing in those N picks can be calculated.<p>(My quick back of envelope sketch says P(H-cycle) = N! / N^N , but please consult the expert literature.)<p>But one can also calculate the probability of a H-cycle given N+1 random picks, N+2 random picks, ... and that appears as \\n = P(H-cycle) * (1 + extra factors that account for increases in other edges not redundantly in the H-cycle)<p>(Again, my back of envelope sketch for N + 2 picks gives:\\n = P(H-cycle) * ( 1 + 2/(N-1)[N - 3 - 1/N]) , but please consult the expert literature.)<p>These probabilities would seem to tell a user that given a graph with N <em>nodes</em> and E edges, that if e.g. in the H-cycle case, E > N the user can get an explicit probability for the likelihood of a H-cycle being present.<p>Are there graph properties that prevent this approach being viable?\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Elegant six-page proof reveals the emergence of random structure\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.quantamagazine.org/elegant-six-page-proof-reveals-the-emergence-of-random-structure-20220425/\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T20:45:57.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"kansface\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Old strings are a different matter. Strings ideally obey Hook's law for small perturbations and undergo simple harmonic oscillation with standing waves (overtones) that have nodes at the neck and bridge (or fret and bridge). With old strings in particular, the fundamental of the string changes over time (as the string sounds). Audibly so! My mental model is that the "length" of the string is a really fuzzy concept for [worn] strings in motion. Plucking the string deforms it, and the string slowly retracts back to the stable length (at rest) as it dissipates energy. I haven't done any math or seen any, but I don't think its linear, either. You can easily verify this using an electric guitar if you plug it into a tuner thing with a visible meter - the arm will swing around. Also, I haven't done any physics in over a decade because I write software now...\",\n \"num_comments\": null,\n \"story_id\": 31143893,\n \"story_title\": \"What Is a Major Chord?\",\n \"story_url\": \"https://www.jefftk.com/p/what-is-a-major-chord\",\n \"parent_id\": 31146575,\n \"created_at_i\": 1651005957,\n \"_tags\": [\n \"comment\",\n \"author_kansface\",\n \"story_31143893\"\n ],\n \"objectID\": \"31172941\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"kansface\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Old strings are a different matter. Strings ideally obey Hook's law for small perturbations and undergo simple harmonic oscillation with standing waves (overtones) that have <em>nodes</em> at the neck and bridge (or fret and bridge). With old strings in particular, the fundamental of the string changes over time (as the string sounds). Audibly so! My mental model is that the "length" of the string is a really fuzzy concept for [worn] strings in motion. Plucking the string deforms it, and the string slowly retracts back to the stable length (at rest) as it dissipates energy. I haven't done any math or seen any, but I don't think its linear, either. You can easily verify this using an electric guitar if you plug it into a tuner thing with a visible meter - the arm will swing around. Also, I haven't done any physics in over a decade because I write software now...\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"What Is a Major Chord?\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.jefftk.com/p/what-is-a-major-chord\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T18:19:44.000Z\",\n \"title\": \"Node v18.0.0 (Current)\",\n \"url\": \"https://nodejs.org/en/blog/release/v18.0.0/\",\n \"author\": \"feross\",\n \"points\": 2,\n \"story_text\": null,\n \"comment_text\": null,\n \"num_comments\": 0,\n \"story_id\": null,\n \"story_title\": null,\n \"story_url\": null,\n \"parent_id\": null,\n \"created_at_i\": 1650997184,\n \"_tags\": [\n \"story\",\n \"author_feross\",\n \"story_31171108\"\n ],\n \"objectID\": \"31171108\",\n \"_highlightResult\": {\n \"title\": {\n \"value\": \"Node v18.0.0 (Current)\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"url\": {\n \"value\": \"https://<em>nodejs</em>.org/en/blog/release/v18.0.0/\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"author\": {\n \"value\": \"feross\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T17:46:32.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"mysterydip\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Sounds like it would allow automatic handling of either failed backend nodes or adding new capacity over time without restarting the proxy, but I could be reading it wrong.\",\n \"num_comments\": null,\n \"story_id\": 31170280,\n \"story_title\": \"Show HN: Caddy v2.5.0\",\n \"story_url\": \"https://github.com/caddyserver/caddy/releases/tag/v2.5.0\",\n \"parent_id\": 31170458,\n \"created_at_i\": 1650995192,\n \"_tags\": [\n \"comment\",\n \"author_mysterydip\",\n \"story_31170280\"\n ],\n \"objectID\": \"31170655\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"mysterydip\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Sounds like it would allow automatic handling of either failed backend <em>nodes</em> or adding new capacity over time without restarting the proxy, but I could be reading it wrong.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Show HN: Caddy v2.5.0\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://github.com/caddyserver/caddy/releases/tag/v2.5.0\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T17:40:13.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"Existenceblinks\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"I found some clue on the docs' TEXTS section.<p>> if the format is hardcoded, the name of the component in which the text resides would be the title<p>So it's component based tracking, though inside-component is hard to form context (e.g. line/column tracking won't work) even if you have AST of javascript. When code changes, AST changes (tree nodes tracking won't work either).<p>Interesting approach not to use hole like `{{ }}`.\",\n \"num_comments\": null,\n \"story_id\": 31166924,\n \"story_title\": \"Show HN: FlyCode – Git-Based Copy and Translations Editor for Web Apps\",\n \"story_url\": \"https://www.flycode.com/developers\",\n \"parent_id\": 31170215,\n \"created_at_i\": 1650994813,\n \"_tags\": [\n \"comment\",\n \"author_Existenceblinks\",\n \"story_31166924\"\n ],\n \"objectID\": \"31170555\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"Existenceblinks\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"I found some clue on the docs' TEXTS section.<p>> if the format is hardcoded, the name of the component in which the text resides would be the title<p>So it's component based tracking, though inside-component is hard to form context (e.g. line/column tracking won't work) even if you have AST of javascript. When code changes, AST changes (tree <em>nodes</em> tracking won't work either).<p>Interesting approach not to use hole like `{{ }}`.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Show HN: FlyCode – Git-Based Copy and Translations Editor for Web Apps\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.flycode.com/developers\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T17:27:02.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"feross\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Founder of Socket (<a href=\\\"https://socket.dev\\\" rel=\\\"nofollow\\\">https://socket.dev</a>) here, a new tool built by npm maintainers to help solve JavaScript supply chain security.<p>A few other ways that attackers get write access to packages that were not covered:<p>1. Maintainer gives access to a bad actor. The most famous case happened in November 2018 when Dominic Tarr gave access to the package `event-stream` to a new maintainer who turned out to be an attacker. This bad actor offered to help maintain the package – something not uncommon in open source. At the time of compromise, event-stream had 1.5 million weekly downloads [1]<p>2. Maintainer goes rogue (i.e. becomes an attacker). The most famous case happened in January 2022 when a maintainer named Marak 'went rogue' and sabotaged his own packages `color` and `faker` which together received over 20 million weekly downloads [2]<p>I believe that the way forward is to assume all open source packages may be malicious. At socket.dev, we use "deep package inspection" to characterize the behavior of an open source package. By actually analyzing the package code, it's possible to detect when packages use security-relevant platform capabilities, such as the network, filesystem, or shell.<p>For instance, to detect if a package uses the network, socket.dev looks at whether fetch(), or Node's net, dgram, dns, http or https modules are used within the package or any of its dependencies. We can detect the tell-tale signs of a supply chain attack, including the introduction of install scripts, obfuscated code, high entropy strings, or usage of privileged APIs such as shell, filesystem, eval(), and environment variables. [3]<p>[1]: <a href=\\\"https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident\\\" rel=\\\"nofollow\\\">https://blog.npmjs.org/post/180565383195/details-about-the-e...</a><p>[2]: <a href=\\\"https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/\\\" rel=\\\"nofollow\\\">https://www.bleepingcomputer.com/news/security/dev-corrupts-...</a><p>[3]: <a href=\\\"https://socket.dev\\\" rel=\\\"nofollow\\\">https://socket.dev</a>\",\n \"num_comments\": null,\n \"story_id\": 31168668,\n \"story_title\": \"Let's talk about supply chain attacks and backdoored dependencies\",\n \"story_url\": \"https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies\",\n \"parent_id\": 31168668,\n \"created_at_i\": 1650994022,\n \"_tags\": [\n \"comment\",\n \"author_feross\",\n \"story_31168668\"\n ],\n \"objectID\": \"31170372\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"feross\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Founder of Socket (<a href=\\\"https://socket.dev\\\" rel=\\\"nofollow\\\">https://socket.dev</a>) here, a new tool built by npm maintainers to help solve JavaScript supply chain security.<p>A few other ways that attackers get write access to packages that were not covered:<p>1. Maintainer gives access to a bad actor. The most famous case happened in November 2018 when Dominic Tarr gave access to the package `event-stream` to a new maintainer who turned out to be an attacker. This bad actor offered to help maintain the package – something not uncommon in open source. At the time of compromise, event-stream had 1.5 million weekly downloads [1]<p>2. Maintainer goes rogue (i.e. becomes an attacker). The most famous case happened in January 2022 when a maintainer named Marak 'went rogue' and sabotaged his own packages `color` and `faker` which together received over 20 million weekly downloads [2]<p>I believe that the way forward is to assume all open source packages may be malicious. At socket.dev, we use "deep package inspection" to characterize the behavior of an open source package. By actually analyzing the package code, it's possible to detect when packages use security-relevant platform capabilities, such as the network, filesystem, or shell.<p>For instance, to detect if a package uses the network, socket.dev looks at whether fetch(), or <em>Node's</em> net, dgram, dns, http or https modules are used within the package or any of its dependencies. We can detect the tell-tale signs of a supply chain attack, including the introduction of install scripts, obfuscated code, high entropy strings, or usage of privileged APIs such as shell, filesystem, eval(), and environment variables. [3]<p>[1]: <a href=\\\"https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident\\\" rel=\\\"nofollow\\\">https://blog.npmjs.org/post/180565383195/details-about-the-e...</a><p>[2]: <a href=\\\"https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/\\\" rel=\\\"nofollow\\\">https://www.bleepingcomputer.com/news/security/dev-corrupts-...</a><p>[3]: <a href=\\\"https://socket.dev\\\" rel=\\\"nofollow\\\">https://socket.dev</a>\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Let's talk about supply chain attacks and backdoored dependencies\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T16:47:36.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"vmoore\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"If you're doing frontend stuff and are adding a bunch of assets hosted off a CDN, you can use Subresource Integrity[0] to ensure the JS file is not tampered with in any way. All it takes is some rogue developer to alter the code of JS used on 1M+ sites to do cryptomining or siphon personal data or do XSS.<p>I know, it's not NodeJS/npm I'm talking about here.<p>npm/Node needs its own resource integrity type feature where we can cryptographically verify the integrity of packages against a known-good library of packages.<p>[0] <a href=\\\"https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity\\\" rel=\\\"nofollow\\\">https://developer.mozilla.org/en-US/docs/Web/Security/Subres...</a>\",\n \"num_comments\": null,\n \"story_id\": 31168668,\n \"story_title\": \"Let's talk about supply chain attacks and backdoored dependencies\",\n \"story_url\": \"https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies\",\n \"parent_id\": 31168668,\n \"created_at_i\": 1650991656,\n \"_tags\": [\n \"comment\",\n \"author_vmoore\",\n \"story_31168668\"\n ],\n \"objectID\": \"31169763\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"vmoore\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"If you're doing frontend stuff and are adding a bunch of assets hosted off a CDN, you can use Subresource Integrity[0] to ensure the JS file is not tampered with in any way. All it takes is some rogue developer to alter the code of JS used on 1M+ sites to do cryptomining or siphon personal data or do XSS.<p>I know, it's not <em>NodeJS</em>/npm I'm talking about here.<p>npm/Node needs its own resource integrity type feature where we can cryptographically verify the integrity of packages against a known-good library of packages.<p>[0] <a href=\\\"https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity\\\" rel=\\\"nofollow\\\">https://developer.mozilla.org/en-US/docs/Web/Security/Subres...</a>\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Let's talk about supply chain attacks and backdoored dependencies\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T15:14:24.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"Pablocarrera\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"Robots moving faster require faster perception computations happening at the edge. This article discusses how hardware acceleration empowers faster robots and how it's important to select the right accelerator. Benchmarking results hint speedup differences of more than 500x between accelerarion solutions for ROS Nodes.\",\n \"num_comments\": null,\n \"story_id\": 31168482,\n \"story_title\": \"Hardware Accelerating ROS 2 Nodes for Perception\",\n \"story_url\": \"https://news.accelerationrobotics.com/hardware-accelerating-ros-2-nodes/\",\n \"parent_id\": 31168482,\n \"created_at_i\": 1650986064,\n \"_tags\": [\n \"comment\",\n \"author_Pablocarrera\",\n \"story_31168482\"\n ],\n \"objectID\": \"31168483\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"Pablocarrera\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"Robots moving faster require faster perception computations happening at the edge. This article discusses how hardware acceleration empowers faster robots and how it's important to select the right accelerator. Benchmarking results hint speedup differences of more than 500x between accelerarion solutions for ROS <em>Nodes</em>.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Hardware Accelerating ROS 2 <em>Nodes</em> for Perception\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_url\": {\n \"value\": \"https://news.accelerationrobotics.com/hardware-accelerating-ros-2-<em>nodes</em>/\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T15:14:23.000Z\",\n \"title\": \"Hardware Accelerating ROS 2 Nodes for Perception\",\n \"url\": \"https://news.accelerationrobotics.com/hardware-accelerating-ros-2-nodes/\",\n \"author\": \"Pablocarrera\",\n \"points\": 1,\n \"story_text\": null,\n \"comment_text\": null,\n \"num_comments\": 1,\n \"story_id\": null,\n \"story_title\": null,\n \"story_url\": null,\n \"parent_id\": null,\n \"created_at_i\": 1650986063,\n \"_tags\": [\n \"story\",\n \"author_Pablocarrera\",\n \"story_31168482\"\n ],\n \"objectID\": \"31168482\",\n \"_highlightResult\": {\n \"title\": {\n \"value\": \"Hardware Accelerating ROS 2 <em>Nodes</em> for Perception\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"url\": {\n \"value\": \"https://news.accelerationrobotics.com/hardware-accelerating-ros-2-<em>nodes</em>/\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"author\": {\n \"value\": \"Pablocarrera\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T15:06:13.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"layer8\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"The difference I see is that an ML model is at first glance not a compiled binary with hidden mechanics: It’s a network graph with weights on the edges and where all nodes work in the same easy-to-understand way. The model also isn’t a unique function of the training data in the way that the compiler binary is a function of the compiler source — you can get slightly differently behaving models from the same training data, so you can’t totally predict the model’s behavior from the training data like you can predict the compiler’s behavior from the compiler source. The model itself is generally the better “source” for predicting (well, simulating) its exact behavior. That’s why it is surprising that the presence of a backdoor can remain undetectable by inspecting the model. There would be somewhat of an analogy if there was a backdoored compiler where the backdoor cannot be detected by analyzing the compiler binary’s machine code.\",\n \"num_comments\": null,\n \"story_id\": 31152452,\n \"story_title\": \"AI can't tell you it's lying if it thinks it's telling the truth\",\n \"story_url\": \"https://www.theregister.com/2022/04/25/machine_learning_verification/\",\n \"parent_id\": 31167779,\n \"created_at_i\": 1650985573,\n \"_tags\": [\n \"comment\",\n \"author_layer8\",\n \"story_31152452\"\n ],\n \"objectID\": \"31168379\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"layer8\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"The difference I see is that an ML model is at first glance not a compiled binary with hidden mechanics: It’s a network graph with weights on the edges and where all <em>nodes</em> work in the same easy-to-understand way. The model also isn’t a unique function of the training data in the way that the compiler binary is a function of the compiler source — you can get slightly differently behaving models from the same training data, so you can’t totally predict the model’s behavior from the training data like you can predict the compiler’s behavior from the compiler source. The model itself is generally the better “source” for predicting (well, simulating) its exact behavior. That’s why it is surprising that the presence of a backdoor can remain undetectable by inspecting the model. There would be somewhat of an analogy if there was a backdoored compiler where the backdoor cannot be detected by analyzing the compiler binary’s machine code.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"AI can't tell you it's lying if it thinks it's telling the truth\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.theregister.com/2022/04/25/machine_learning_verification/\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T14:21:11.000Z\",\n \"title\": \"Node.js 18 Release: What's New\",\n \"url\": \"https://blog.appsignal.com/2022/04/26/nodejs-18-release-whats-new.html\",\n \"author\": \"Liriel\",\n \"points\": 1,\n \"story_text\": null,\n \"comment_text\": null,\n \"num_comments\": 0,\n \"story_id\": null,\n \"story_title\": null,\n \"story_url\": null,\n \"parent_id\": null,\n \"created_at_i\": 1650982871,\n \"_tags\": [\n \"story\",\n \"author_Liriel\",\n \"story_31167798\"\n ],\n \"objectID\": \"31167798\",\n \"_highlightResult\": {\n \"title\": {\n \"value\": \"Node.js 18 Release: What's New\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"url\": {\n \"value\": \"https://blog.appsignal.com/2022/04/26/<em>nodejs</em>-18-release-whats-new.html\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"author\": {\n \"value\": \"Liriel\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T12:38:50.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"silicaroach\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"javascript/nodejs. I had been using Matlab ~15 yrs until I left the institution that was paying for it. I looked around and js/node was the clear winner. NodeJS was being continually improved with faster engines, the browser as the default GUI for any app I could create, Node can access to C libraries directly. So though I didn't know it at the time, I became full stack dev. And that is on top of my real job of engineer/data scientist. Unlike a lot of my colleagues who know only python/Fortran/C/C++ I'm comfortable putting together a server to crunch the numbers, tap in to a dB, and serve it all to a GUI of my own design if need be. JS/Node is not easy but it is the most flexible language ... oh, and you'll never be out of work even if that's the only language you know.\",\n \"num_comments\": null,\n \"story_id\": 31165756,\n \"story_title\": \"What's a good general-purpose programming language?\",\n \"story_url\": \"https://www.avestura.dev/blog/ideal-programming-language\",\n \"parent_id\": 31165756,\n \"created_at_i\": 1650976730,\n \"_tags\": [\n \"comment\",\n \"author_silicaroach\",\n \"story_31165756\"\n ],\n \"objectID\": \"31166712\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"silicaroach\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"javascript/<em>nodejs</em>. I had been using Matlab ~15 yrs until I left the institution that was paying for it. I looked around and js/node was the clear winner. <em>NodeJS</em> was being continually improved with faster engines, the browser as the default GUI for any app I could create, Node can access to C libraries directly. So though I didn't know it at the time, I became full stack dev. And that is on top of my real job of engineer/data scientist. Unlike a lot of my colleagues who know only python/Fortran/C/C++ I'm comfortable putting together a server to crunch the numbers, tap in to a dB, and serve it all to a GUI of my own design if need be. JS/Node is not easy but it is the most flexible language ... oh, and you'll never be out of work even if that's the only language you know.\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"What's a good general-purpose programming language?\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"story_url\": {\n \"value\": \"https://www.avestura.dev/blog/ideal-programming-language\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n },\n {\n \"created_at\": \"2022-04-26T11:27:49.000Z\",\n \"title\": null,\n \"url\": null,\n \"author\": \"Shadonototra\",\n \"points\": null,\n \"story_text\": null,\n \"comment_text\": \"that's why we then have people in the car industry making sluggish UI interfaces with nodejs on resource constrained terminals\",\n \"num_comments\": null,\n \"story_id\": 31164858,\n \"story_title\": \"Non-Tech Founders Conundrum -How do I hire the right tech talent for my startup?\",\n \"story_url\": null,\n \"parent_id\": 31165894,\n \"created_at_i\": 1650972469,\n \"_tags\": [\n \"comment\",\n \"author_Shadonototra\",\n \"story_31164858\"\n ],\n \"objectID\": \"31166123\",\n \"_highlightResult\": {\n \"author\": {\n \"value\": \"Shadonototra\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n },\n \"comment_text\": {\n \"value\": \"that's why we then have people in the car industry making sluggish UI interfaces with <em>nodejs</em> on resource constrained terminals\",\n \"matchLevel\": \"full\",\n \"fullyHighlighted\": false,\n \"matchedWords\": [\n \"nodejs\"\n ]\n },\n \"story_title\": {\n \"value\": \"Non-Tech Founders Conundrum -How do I hire the right tech talent for my startup?\",\n \"matchLevel\": \"none\",\n \"matchedWords\": []\n }\n }\n }\n ],\n \"nbHits\": 22733,\n \"page\": 0,\n \"nbPages\": 50,\n \"hitsPerPage\": 20,\n \"exhaustiveNbHits\": true,\n \"exhaustiveTypo\": true,\n \"query\": \"nodejs\",\n \"params\": \"advancedSyntax=true&analytics=true&analyticsTags=backend&query=nodejs\",\n \"processingTimeMS\": 9\n}"
}
]
}
],
"event": [
{
"listen": "prerequest",
"script": {
"type": "text/javascript",
"exec": [
""
]
}
},
{
"listen": "test",
"script": {
"type": "text/javascript",
"exec": [
""
]
}
}
],
"variable": [
{
"key": "TOKEN",
"value": "",
"type": "string"
}
]
}