Syllabus, CMPTGCS 1A, Fall 2018
Basic Facts
- Instructors: *Richert Wang
-
Lecture: TuTh 11:00am-12:50pm CCS 143.
- Office Hours: See:
- TBD
For course website links, visit https://ucsb-cmptgcs1a-cmpsc24a-f18.github.io.
About the Course
Course Description:
This course is the first half of a two quarter sequence (CMPTGCS 1A, CMPTGCS 1B) designed to prepare students to take upper division courses in Computing, and participate in undergraduate research projects in Computing under the direction of CCS and College of Engineering Computing faculty.
In both quarters, the course is paired with CMPTGCS 1L, “Programming Lab”, where students undertake individual and group programming projects to build and reinforce their skills and knowledge.
1A provides students with the opportunity to build skills and knowledge in the following areas: problem solving and algorithm development, C and C++ programming, software development tools, programming language paradigms (structured, functional and object-oriented programming), basic UNIX utilities and tools, basic data structures including arrays and linked lists representations of lists, stacks, queues, and binary trees, binary and linear search, sorting techniques, iteration vs. recursion, basic running time analysis, data representation.
In addition to basic skills in C and C++ (which is a fundamental preparation for upper division CS courses at UCSB), other programming languages such as Java, Scheme, Python, JavaScript and others may be explored either because of the principles they illustrate, or based on student interest.
Required Text
- Savitch, W. Problem Solving with C++, 10th Edition Pearson
- Main, M. and Savich, W. Data Structures and Other Objects Using C++, 4th Edition Pearson
Accommodations for disabilities
Information about how UCSB supports students with disabilities is available at the campus ADA website: http://www.ada.ucsb.edu. If you require any special accommodations due to disabilities, please let me know as soon as possible. You may contact me by email to request an appointment.
Managing stress
Personal concerns such as stress, anxiety, relationships, depression, cultural differences, can interfere with the ability of students to succeed and thrive. For helpful resources, please contact UCSB Counseling & Psychological Services (CAPS) at<PHONE_NUMBER> or visit http://counseling.sa.ucsb.edu/.
Standard Disclaimer
This syllabus is as accurate as possible, but is subject to change at the instructor’s discretion, within the bounds of UC policy.
(end of syllabus)


Getting started with deviantart for python¶
‘deviantart’ is a python package that provides easy access to the deviantart API.
Contents¶
Disclaimer¶
This is an unoffical package for the Deviantart API and I’m not affiliated with Deviantart. I work on this API wrapper in my free time and even though I try to keep it up to date, I can’t guarantee and vouch for its functionality at any time. Please keep that in mind while working with this package.
License¶
The deviantart python package is licensed under the MIT license.


Vetanda Dance Collective is an entertainment company comprised of dancers residing throughout the New York City area. With emphasis on creating an immersive experience, Vetanda's jazz inspired movement puts a contemporary twist on conventional cabaret style performances. Vetanda aims to continue challenging and exploring the role of dance in nightlife settings to further enhance the audience experience. Since its debut, Vetanda has performed at a range of venues around Manhattan, such as The Norwood Club, The Duplex, and Coney Island Baby. They have also been featured in music videos by musical artists Diana Bidèa and Downaman.


Lines are generally used to separate parts of a window. A line is used to make the window look better and help organize the GUI elements.
Lines are passive widgets, meaning that they do not respond to button clicks or keystrokes.
The x1 and y1 parameters specify one end-point of the line and the x2 and y2 parameters specify the other end point. The line must either be horizontal or vertical (i.e. x1 must equal x2 or y1 must equal y2). The kind parameter specifies the type of line. This is one of 0, GUI.LINE, GUI.INDENT or GUI.EXDENT. A kind of 0 is the default and is the same as GUI.LINE.
GUI.INDENT and GUI.EXDENT only display properly if the background colour has been set to gray using GUI.SetBackgroundColor. GUI.INDENT makes the line appear indented or recessed. GUI.EXDENT makes the line appear to stand out from the window.
import GUI
View.Set ("graphics:180;100,nobuttonbar")
GUI.SetBackgroundColor (gray)
var line, indentLine, exdentLine : int
var lineLabel, indentLabel, exdentLabel : int
line := GUI.CreateLine (30, 20, 30, 90, 0)
indentLine := GUI.CreateLine (90, 20, 90, 90, GUI.INDENT)
exdentLine := GUI.CreateLine (150, 20, 150, 90, GUI.EXDENT)% Label the lines.
lineLabel := GUI.CreateLabelFull (30, 15, "Line", 0, 0,
GUI.CENTER + GUI.TOP, 0)
indentLabel := GUI.CreateLabelFull (90, 15, "Indent", 0, 0,
GUI.CENTER + GUI.TOP, 0)
exdentLabel := GUI.CreateLabelFull (150, 15, "Exdent", 0, 0,
GUI.CENTER + GUI.TOP, 0)
A line widget is a passive widget and cannot be enabled or disabled.
| GUI.Show, GUI.Hide, GUI.Dispose, GUI.GetX, GUI.GetY, GUI.GetWidth, GUI.GetHeight, GUI.SetPosition, GUI.SetSize, GUI.SetPositionAndSize |
This means that you can only call the function by calling GUI.CreateLine, not by calling CreateLine.


2020 Mitsubishi Mirage Arrives With Fresh Styling And Value
Will this facelift be enough to keep sales momentum?
by Jay TraugottThe Mitsubishi Mirage G4 sedan and Mirage hatchback are proving to be hot sellers throughout the world, including the US. Last year, a total of 24,316 examples were sold (sedan and hatchback) in America. Both are only basic transportation, but they also have very affordable starting prices: $14,795 for the sedan and $13,795 for the hatch. Today, Mitsubishi has revealed the facelifted 2020 Mirage G4 and Mirage at the 2019 Thailand International Motor Expo.
The facelift applies the Japanese automaker's new and more dynamic front-end styling along with a number of interior upgrades. Mitsubishi calls the front end look Dynamic Shield styling, which features new multi-bulb LED headlights connected visually with the grille. Fog lamps are located at the bumper corners. Not everyone may be a fan of the styling, but it's certainly bold, perhaps too much for a subcompact car like this.
The rear end also receives a bit of restyling, specifically with a wider and more stable look, incorporating a more squared-off approach for the bumper corners and L-signature horizontal LED taillights. The exterior updates are completed with new 15-inch alloy wheels with two-tone diamond-cut styling and two new exterior color choices, White Diamond and Sand Yellow.
The interior has also been upgraded with redesigned front armrests and improved build materials. The power window switch panel, for example, has a carbon pattern. Higher trim levels come with a sporty-look fabric/synthetic leather combination. The seat sides also receive piping and stitching. Perhaps most importantly is the addition of the automaker's new Smartphone Display Audio system. This is a seven-inch touchscreen that offers full smartphone connectivity including Bluetooth and Apple CarPlay and Android Auto Connectivity.
You Might Also Like
Under the hood, the 2019 Mirage twins are powered by just one engine option: a 1.2-liter inline-three engine with 78 horsepower and 74 lb-ft of torque. Power is directed to the front wheels through a five-speed manual or a CVT. Mitsubishi has not implied this setup will change.
Official pricing has not been announced but sales are likely to begin early next year.


Rusty Russell, Joe Netti (2019-08-12)
Transcript By: Michael Folkson
Category: Podcast
Stephan Livera podcast with Rusty Russell and Joe Netti - August 12th 2019
Podcast: https://stephanlivera.com/episode/98/
Stephan Livera: Rusty and Joe, welcome to the show.
Joe Netti: Hi. How’s it going?
Rusty Russell: Hey, Stephan. Good to be back.
Stephan Livera: Thanks for rejoining me, Rusty, and thanks for joining me, Joe. So, just a quick intro just for the listeners. Joe, do you want to start?
Joe Netti: Yeah, sure. So, I got into Bitcoin in around 2013, and took me a while to learn what it was about, and then I just kept diving deeper. Now, I go to school at RIT in New York studying computer science, and this past spring I did an internship at Blockstream where I was with the Lightning team, with Rusty and with others, working on Million Channels Projects and some plugins and Lightning, and that’s where I am today, just interested in Lightning and Bitcoin and all that jazz.
Stephan Livera: Yeah, it must be awesome to be interning at Blockstream. Rusty, look, I think all my listeners know who you are, but maybe just take a minute. Just for the ones who don’t know you, just take a minute and tell us what you’re working on these days and what’s your role.
Rusty Russell: Yeah, so, I guess, mostly I’m known for my work on the Lightning implementation, c-lightning, and the spec efforts. So, like obviously, all the implementations we work together to try create specification, which really, I mean, I consider more important than the implementation, right? Code, you can throw away, but you’re stuck with whatever you agreed with to interoperate, right? So, that’s what I see as my main role is to ship at that spec process and bring everyone together on that, and that’s obviously pretty exciting. Lots of lots of great stuff coming down the pipe there.
Rusty Russell: Also, I’ve got the team at Blockstream, three of us now, doing the c-lightning implementation and a whole heap of other people. It’s an open source project. We get a lot of cool contributions, single drive-bys, and more significant contributions. In fact, they name you at the releases, which we’ve got a release coming out tomorrow. Well, actually, one of them come out tomorrow, so the rest come out next week. The release gets named by whoever’s done the most contributions in the last cycle or who hasn’t already named it, so it’s always fun to see who’s going to get to name the release. We have a stave for our release names, but that’s an open secret among people who’ve named it already.
Rusty Russell: So, yeah, my job’s to shepherd those two projects mainly and just random things with Blockstream and everything else. So, there’s always a whole heap of stuff going on. The first intern I have had was Joe, actually, which has set me up. I think I’m really well, like my expectations are really high for what interns should do, because Joe did amazing work on the Million Channels Project, but he also, in his copious spare time that that left him somehow.
Rusty Russell: He also did great GraphQL plugin stuff for us. That’s really exciting, obviously, that you’ll be hearing more about in the future as well, I expect. So, yeah, I guess that’s me, and that’s us, and how things are working.
Stephan Livera: Sure. Great. Yeah, that’s awesome. So, look, and the topic or our theme for today is the million channel experiment. So, let’s start with a little bit of what spurred this experiment.
Rusty Russell: Cool. So, the backstory is… Now, we’ve seen this sort of explosive growth in the Lightning Network. It went from it doesn’t know it’s in 2018 that it started on mainnet, and it kept growing, and we’ve seen some teeny problems with scalability issues a couple points, and there was this idea. “What we should do is we should simulate an endgame, like what it’ll look in a million channels,” which is a normal…  It’s actually not such a big number now. I think we’re around a 20th of that now.
Rusty Russell: So, at the time, it was like, “Wow. Wonder 100 times bigger, what will things look like?” I had this idea, never had time to implement it. Ended up putting it in a blog post, going like, “Hey. It’d be really cool to do this Million Channels Project where we simulate what the network might look like if we scaled it up. We had a million channels and however many nodes that is and everything else. Then we could basically simulate that and throw some existing software at it, and let’s watch it fall over and die.”
Rusty Russell: Obviously, you find out that, that way, what was going to happen when we got that big because it’s like the whole idea with implementations has been where there’s been so much stuff to do that optimizing hasn’t necessarily bubbled to the top, except as you need to put out fires, right? So, to try to get ahead of that, the idea for Million Channels Project was to create this real stress test, this genuine thing. Then when Joe came along as an intern, he was really excited about it and saying, “Right,” and then he basically took that between his teeth and ran with it.
Stephan Livera: Awesome. So, Joe, let’s hear from you a little bit. What was your experience like with setting up and taking part in this, and as I understand, you took a snapshot of the current Lightning Network, and you used that to help inform this project?
Joe Netti: Mm-hmm (affirmative). Yeah, it’s really cool. All right, so basically, it started as a very open-ended project. There’s quite a lot we could do. We could make a regtest network. We could simulate it to as precise as we want it to, so it was very open-ended, and I had to define what I wanted to do. So, it took me a while to dance around, to understand what the current properties of the snapshot of Lightning Network was and then make an algorithm that would make a larger also accurate Lightning Network. Should I go into the properties right now, about what I learned about the snapshot and stuff?
Stephan Livera: Yeah, sure. Let’s do that. Do you want to maybe tell us what is regtest mode as well?
Joe Netti: Sure, yeah. So, regtest is something that a lot of Bitcoin developers use to test their applications. Instead of using the main chain, they use this very lightweight local chain and tool called regtest mode in bitcoind on Bitcoin Core. It allows you to make blocks with… that you’d basically have no difficulty, so you could just mine blocks, you can just make transactions, and you can make a fake chain so that you can test your application.
Joe Netti: Since the Million Channels Project made a large-scale Lighting Network, each channel in Lightning Network also has funding transactions. So, well, I made a regtest replica of all of those funding transactions, basically a fake chain with blocks with all these funding transactions that matched what the Lightning Network was, and that was pretty cool.
Rusty Russell: Which was much cheaper than giving him a million dollars to do it on the real chain.
Joe Netti: Exactly. Exactly.
Stephan Livera: Let’s talk a little bit about the gossip of Lightning nodes. So, how do Lightning nodes gossip to each other right now?
Rusty Russell: So, basically, you’ve got two parts of the Million Channels Project. We want to step back a bit. One is this. You obviously need a blockchain because what happens is, as a layer two thing, you need a layer one. When a node says, “Hey, I’ve got this channel. You actually check on the blockchain that actually exists.” So, you do need the two parts, so you have this regtest fake blockchain, but you also have all these gossip messages, and the gossip messages are basically, “Hey, here’s this new channel, and I can prove it, right? I can prove that I own this channel.” That basically tells you where in the Bitcoin blockchain to find the transaction that hasn’t been spent yet. It is the right size.
Rusty Russell: You go, “Yeah, cool. I believe you. You two definitely have this channel. Good.” That’s the channel announcement. There’s a channel update, which is basically, “Hey, I decided I’m going to charge this amount of fees and stuff like that,” and you have two of those. You have one for each direction because I control my half of the channel; you control your half. “Oh, cool. I’m going to start charging these fees on stuff going through my half of the channel my duration,” right?
Rusty Russell: I know you have node announcements. So, nodes basically announce stuff like, “Hey, here’s where you can reach me. Here’s my IP address. Here’s where you can access me on Tor. Here’s my favorite color, and here’s my alias.” We literally have these two fields in there, which people love, right? They’re completely from one sense. They’re completely useless in one sense, like you can call it your node something, and I can see it on explorers, and I can call my node exactly the same thing, and no one will be able to distinguish, right?
Rusty Russell: There’s this public key that can distinguish them, but the node name, anyone can make up, right? So, they’re not secure. They’re just for fun, but it proved to be like a really useful thing. But the node now really is for advertising where how you can connect to a node and stuff like that if you want to establish the right channel.
Rusty Russell: So, you have all this gossip, right? You basically have this, “What did it turn out to be? Do you know? Is it like 70 megabytes or something?” Basically, just this fire hose. Here’s everything about the network once.
Stephan Livera: 731.
Joe Netti: And more than 730. Yeah, 730 megabytes.
Rusty Russell: 730, yeah. Yeah, it’s a chunk of data, right? That is basically think it like this new node going up, going, “Hi. I’m new on the network,” connects to one of these other nodes. Here’s why. Here’s the million channels that you don’t know about and just would throw 730 megabytes at it of this entire description of the entire network. So, you can see the kind of things that we’re dealing with when you’re looking at, “Wow, okay, that’s fun for an implementation to handle that.” So, yeah, that’s the gossip, right?
Rusty Russell: There’s this pre-canned gossip, which is basically like, “Here is the description as if you had connected to a new node,” and it was going to tell you everything about it. This is it, and it’s 731 megabytes, right? It’s a chunk.
Joe Netti: Yeah, can I add to that?
Stephan Livera: Yeah, sure. Go for it.
Rusty Russell: Yeah.
Joe Netti: So, basically, you can split the million channels into three parts. You can see it as taking a snapshot and making a larger simulated network, and then the second part is making the regtest data, and then the third part is making the gossip data. Rusty just described the gossip part of that. So that’s literally channel announcements, channel update messages, and node announcements.
Rusty Russell: Yeah, so I know you’re probably going to segue into this, but this is where Joe and I intersects, right? He produced this massive… “Here’s 730 megabytes, Rusty,” and I tried to feed it into c-lightning and watched it like slow to a crawl. I remember the first time Joe tried to feed it in. He was like, “Well, it’s been running all night, and it hasn’t even [inaudible 00:10:47] yet.”
Joe Netti: Oh, man that was horrible, yeah.
Rusty Russell: Yeah, yeah, like there were just some dumb stuff that we completely hadn’t looked at. What are we doing with this significant amount of data here? So, there was a whole heap of iterations of trying to get this all manageable, because on the scale of over 20…
Rusty Russell: So, for me, the exciting part was actually taking this massive gossip output he produced and trying to cram it into one of my nodes and watch it fail in different ways.
Joe Netti: Yeah. It was crazy how many iterations there were with Rusty’s optimizations. There was a wave of optimizations and a second wave and third wave. It just kept coming.
Rusty Russell: Yeah, but it was never fast enough, right?
Joe Netti: True.
Stephan Livera: So, in order to create that estimate as well, so as part of the regtest part of this experimental project, you had to create all the funding transactions, which is when somebody is starting and opening a lightning channel. So, what was your process there around trying to simulate that?
Joe Netti: Yeah, so that wasn’t that bad. Basically, I just grabbed the Python library that allowed you to make scripts and custom scripts and stuff.  The hardest part… That wasn’t that hard. The harder part was… Actually, I will mention this.
Joe Netti: The Python library I was using was so slow with signatures that I didn’t want to rewrite it in different language after I already wrote it. So, I just ended up doing this massive threading thing where, well a really paralyzed thing where I just made a bunch of signatures paralyzed because it was just so slow. So that was funny, but yeah.
Rusty Russell: Also was funny that you ran out of money, right?
Joe Netti: Oh my God. That was [crosstalk 00:13:12].
Rusty Russell: To actually create the-
Joe Netti: Yeah. So, it’s a weird quirk in regtest mode.
Rusty Russell: Who knew, right?
Joe Netti: So, you know the Bitcoin halving, there’s every, like I think around two year is a halving. Well, in regtest mode, since they want developers to be able to experiment with what happens when there’s a halving, they have halvings every like 250 blocks or so, and that’s nothing. I didn’t want to have developers that are using Million Channels Project to have to go in and recompile Bitcoin Core… change parameter, recompile Bitcoin Core. So, we had to actually scale down all the channel capacities set by a factor of… I don’t know, like 10,000 or something like that, so they would actually wouldn’t run out of money. That was dumb, but it’s pretty cool.
Rusty Russell: There were literally not enough regtest Bitcoins because it halves too fast, and this is something we just didn’t even realize playing around with it, and then Joe’s like, “I’m out of money.” I’m like, “How are you out of money?”  So, there were some quirks in there of like trying to simulate this massive network. So, it ended up like this model train version where it’s scaled down, but the math doesn’t matter, right? Who cares, right? One Bitcoin is one bitcoin. It’s all the same, but it was just an added hurdle in there that Joe discovered.
Joe Netti: I like that model train example. That’s basically what we’re doing is making a mini example of what Lightning Network could be.
Stephan Livera: Yeah, and as part of that then, you’ve got this power law distribution, which you used to model all that out as well in terms of how many nodes there are, how many channels those nodes have, and what is the capacity of those channels. Can you comment a little on that?
Joe Netti: Yeah, definitely. So, there is about four properties of the Lightning Network that I thought would last in the future, and that’s what we’re doing. We’re going to predict what Lightning Network’s going to be and take away the properties that are fundamental to how this network will work. One of them is that there’s a power law distribution, and a power law is basically, like you can imagine, like a hockey stick. There’s a power law distribution of the number of channels across nodes.
Joe Netti: So what I mean by that is around 20% of the nodes will have one channel only. Around 10% might have two channels. Around maybe 5% will have three channels and so on. It gets less and less and less in a power law distribution. You could search that up. That’s cool. It shows that there might be long-term hubs where there’s a small amount of nodes that have a lot of channels. Maybe it could be like a thousand channels maybe and then most nodes only have one to five. So, I try to get that property into the simulation. On top of that, there’s a second property.
Rusty Russell: Certainly, to be fair, we’re seeing that today, right? So, we have a certain number of whales. We have a whole heap of minnows. We have a whole heap of range in between, but that is definitely the way of the network. This is a lot of things, right? So, Joe… He’s got his power law. He describes a lot of natural networks that occur. You end up with a certain number of huge things and a small number of large things and then like in a whole heap of minnows, and that’s definitely what we see today. I think Joe latched on that as like, “Okay, that’s pretty well established. That’s going to continue.”
Joe Netti: Right, exactly, and not only with number of channels. It’s also true with the amount of Bitcoin that is held by each node. There’s some small amount of nodes that have just a ton of Bitcoin in their channels and then some nodes that have a very small amount of Bitcoin in their channels, and it follows the same distribution, which is also the second property that’s modeled in this new network.
Stephan Livera: Right. You’ve got your Bitrefills and your LNbigs of the world.
Joe Netti: LNbigs.
Stephan Livera: And then you’ve got… Yeah. I’m also interested to talk a little bit about routing. Now, Rusty, I’ve seen some… You had a few blog posts talking about this, and I think back in the earlier days, you were talking about how you had this approach of Bellman-Ford-Gibson. Maybe we’ll just start with a few basic points around routing. What are some of the things that we should think about there and what were some of the decisions made around know what algorithm to use?
Rusty Russell: Cool, so, yeah. First, when we talk about routing and for privacy reasons, the sender decides where the routing’s is right, so we look through and go, “Okay.” You decide how to get the payment to the recipient. It’s also because you’re paying fees at each point, right? So, you have to know what fees you’re going to have to pay. So, you preload that into your payment. But also, each layer basically unwraps it and then, “Oh. Okay, so that’s who’s going next.” The hops on the path can only see where it just came from, where this was sending to.
Rusty Russell: So, that provides anonymity for the sender, and it provides obfuscation for the receiver, right? The receiver doesn’t know where the sender came from. The sender obviously knows where the receiver is, but the sender, no. In order to make that work really well, you have to have a fixed-sized thing that’s going through, obviously, if you decrypted it, took the head off, and sent the rest of it along. It would get smaller. The message would get smaller.
Rusty Russell: If you went, so if you did it naively, and you be like, “Look at the size. Well, I reckon the next hop is the last one,” right? Which would obviously leak too much information, so you have to pick a number. How big is this? You’re going to pad it as you go through, but all of them need to be the same size, so that’s a good number. We chose 20 because, well, it’d cost us this much for each hop. We multiply it out. We want to be able to fit it in one TCP packet in 300 bytes, but let’s go for 20.
Rusty Russell: Interestingly, even in the Million Channels Project, this was not an issue. Even with a million channels, you didn’t need to use 20 hops. I don’t think… Joe, did we actually measure the worst case, which, from the furthest two points?
Joe Netti: Yeah, I don’t think we did, but I highly doubt it actually reached 20.
Rusty Russell: Yeah, we might’ve been able to find some perverse thing that maybe thought close, but generally, no. You didn’t need anything like this. So that shows that, and that we… The 20 was way more than we probably needed. Interestingly, we just merged in the spec change of variable onion. So we’ve actually bumped that number up. Rather than each one being fixed, we now go for a variable-sized chunk that you take. So, we still got the same total, but actually, you can squeeze things in a little bit more, and you could probably get to 24. The reason you do that was actually the reverse that we want to cram more information in for some hops.
Rusty Russell: But as a side effect, we can actually probably get out to maybe 28, I think, is the new reasonable… but we don’t need it, right? Even for the 10 Million Channels Project, I think we’re still going to be good for 20 hops. That’s why we have that kind of limit there.
Joe Netti: Yeah, part of reason why I think we’re also good is just if this power law thing continues, then there’s going to be these hubs. Basically, some nodes will have a lot of channels, and that’ll help us not reach this 20 whatever limit right.
Stephan Livera: Right, so we’ve got this idea then that more hops can theoretically give you more privacy, but that’s additional packing of fake layers, as you mentioned, the padding, and then if it’s less hops, then theoretically it’s cheaper because you’re going less hops in the route. Rusty, can you also chat about how I think in the earlier days, there was that concept of potentially having negative cost for rebalancing and then that being removed from the spec?
Rusty Russell: Yeah, so it didn’t make it into the spec 1.1, but it was originally this idea of, “Hey, you can offer people money to use your routes,” right? Andreas Antonopoulos said this really good analogy of a channel, like a PVC pipe with peanuts in it, right? All the peanuts started on my end, and I send peanuts across to your end. I like this because it just shows that whole channel balance problem, right?
Rusty Russell: So, you do want to keep your channels balanced, and there was this idea that, “Well, what I could do is I could provide negative fees by just basically paying other people to balance the channel for me.” If you use this channel, I will actually pay you to send some money through because I want you to balance. Christian Decker points out that that doesn’t actually make sense because you could do that yourself by routing round in a circle.
Rusty Russell: You go, “Well, I can push out through that node and around through that node and back to that node, and then I can push payments around to rebalance my own channels.” If it’s expensive for me to do that, so if that actually starts making sense, you go, “Well, then other people will start routing through that way anyway.” So, it turns out there isn’t actually a huge demand for providing this kind of liquidity because you can do it yourself.
Rusty Russell: The other thing is that, ideally, you don’t think negative. You just seem to be cheaper than everyone else. Now, at the moment, we’re seeing ridiculously cheap fees for routing of a light network. It’s probably not sustainable. I expect long term, they will go up just simply you can’t charge like a millionth plus one satoshi for a payment. At one millionth, it’s just not enough to keep the lights on. So, I expect those numbers to creep up. People want reliable nodes. They want them to be on all the time. They want them to have high availability, lots of capacity. That number is going to have to increase.
Rusty Russell: Once that has increased, then you don’t need to go negative. You can just go, “Well, I’m just going to go really cheap,” and people will start funding through this. Also, from a technical perspective, it turns out the number of algorithms break down if you have negative fees, right? Your algorithms really want to start routing… Use your 20 hops to go round in a circle as many times as you can to go through that negative fee one to collect as much money as you can. You have these really weird situations where the ideal is strange.
Rusty Russell: So, negative fees actually just from a computer science point of view becomes difficult. That didn’t make it into the spec, there wasn’t enough conviction that it needed to go in, and I doubt at this stage it’s going to. Of course, you could always implant negative fees on top, like I promise that if you try to use it.  Now, normally, that would match what they advertise, right? They’ll be like, “Well, yeah. I said you had to pay 0.1% plus 10 satoshis,” and that’s what you’ve done.
Rusty Russell: If you don’t know, they can choose to accept it anyway. They go, “Oh, you’re overpaying me on fees, but that’s cool. I’m happy with that,” or you’re paying less. So, you could have some external thing where someone advertises, “Hey.” They tweet out, “Hey, if you route through here, I will accept negative fees. I will actually pay you to do this.” If that becomes a popular, then we’ll make it a mainstream thing. I can put in the gossip algorithm and make it all work, but we haven’t seen a huge demand for that at the moment.
Stephan Livera: Great. Joe, did you want to comment a little bit around the differences that you see between the Bellman-Ford-Gibson versus the Dijkstra algorithm?
Joe Netti: I don’t have too much to add to that.
Stephan Livera: Okay, sure. Rusty, did you want to comment a little on that as well?
Rusty Russell: Yeah. Okay, so we went for this superb elegant algorithm that basically will give you the best at the cheapest route for every possible distance. So, because you’ve got this in this hard limit, like it doesn’t matter how cheap a route is. It’ll take you 21 hops to get there. As I said, normally, we don’t hit that, but it’s quite possible if somebody could deliberately force you into that by creating this long chain of nodes that just designed to mess with your implementation.
Rusty Russell: They’ll create a long line of channels that goes like just this whole loop that’s like 20 long. That’s free, right? The computer science, like your dumb routing algorithm is just going to fall down that hole all the time, and they’re going to keep trying to route through that. They go, “Oh, but wait. It’s the cheapest, but I can’t use it because now, it’s 21 hops,” right? So you do have to be robust. You have that kind of adversarial behavior even though it, quote, “never happens.”
Rusty Russell: So, Bellman-Ford-Gibson is incredibly elegant and will give you the best answer for every possible distance, right? Like for zero to 20, it’ll say, “It’s not possible to get there in less than five hops, and here’s the… ” Look at the [inaudible 00:26:00]. Cool, even in seven hops, and that’s cheapest. If it goes this path. Great. It gives the answer all at once, but it’s relatively slow, and the Million Channels Project, it really starts to divide us. Actually, that’s starting to hurt.
Rusty Russell: Okay, so we have to do something less than perfect, and you have a lot of wiggle room here because basically these are so low, but you don’t actually need the cheapest path, right? You need something competitive. But if you’re paying an extra 10 millisatoshis, nobody cares. They really don’t care, right? To remember, like if Bitcoin hits a million dollars, then one satoshi is one cent. So, at that point when Bitcoin has like totally mooned, and a satoshi is worth a cent, a millisatoshi is still a fraction of a cent, right? Nobody cares.
Rusty Russell: So, you can do a whole heap of approximations, and there’s this great algorithm called Djikstra. It’s really fast, but it doesn’t handle… it falls off a cliff if you have more than… If you have some kind of length limit. So, what you do is you run that, and most the time there’s no adversarial network.  But then if it doesn’t work, you still have to fall back on something that can handle the hard cases, and that basically cut through a lot of the stuff that we were doing. It meant that we had a much faster competitive routing algorithm.
Rusty Russell: There’s more room to go there, right? It’s just completely generic. Most of the time you’re asking the same question, which is how do I get from my node to somewhere else? You’re asking the same question over and over again. So, you can engage in all of the stuff. We can get smarter. There’s already been some talk of, “How do we handle really massive rates of queries?” I did a measurement recently on the current one on my Raspberry Pi. It takes on average, if I pick two random nodes, to get a route between them.
Rusty Russell: To get an answer back, it takes an average of 300 milliseconds, right? That’s on my little Raspberry Pi. It’s this tiny little Pi 2 B computer. It was the previous generation of Raspberry Pi. So, I run that just so I can do these kind of tests. Now, a third of a second’s not fast, but it’s not slow either, right? That’s acceptable in your mobile phone. So, your cellphone, you hit route, it takes 30 seconds to figure it out. That’s okay, but we can definitely get more aggressive, and we can do even more stuff on top of that.
Rusty Russell: There’s been talk of what do we do because what happens if that first route fails? You have to find another one that goes around that bit. Yeah, we can do a whole episode on the fun of routing algorithms, but basically, yeah. This was one of the great outcomes of this project. So, yeah, this really is going to be a problem here. We really can do better. There was no immediate intent to do it today, but Joe threw this stuff at me, and I’m like, “We’ve got to get that on this, right? We can’t take 10 seconds to route through this thing. We’ve got to cut loss of seconds.
Rusty Russell: So, the numbers are in the blog post, and yeah, Dijkstra was a big improvement although we have to have this fallback approach. To handle hard cases.
Stephan Livera: Right, and as I understand, with the routing algorithm using Dijkstra, is that something at a specification level or is that more of a c-lightning level?
Rusty Russell: Yeah, more of a c-lightning level. I mean, yeah, you pick how… You’ve got the graph. You’ve got the map. You figure out how to get there, right? It’s more freeing in a way. I don’t have to ask anyone else. I can just go and go, “Okay, let’s try this and do stuff.” But yeah, some of that knowledge, of course, is shared between all of the teams though. So, even that implementation details stuff, we do talk all the time about. “Hey, how are you guys solving this? How are you doing this one?” So, there’s a lot of informal communication, but it doesn’t have to be at a spec level.
Stephan Livera: Let’s talk a little bit then. So, you mentioned there around the RasPi and trying to make it work for the RasPi. Versus routing from a desktop-level PC. How do you think about that? Is it going to be most… Do you think most users are going to be out on a mobile, and they’re going to have to route from a mobile? Or is it more like that mobile is connected back to their, say, their desktop PC, so therefore, they can let the desktop PC do the heavy lifting?
Rusty Russell: I think it’s clear that we’re headed… We’re an all mobile world now, right? So, you really do have to fit into that form factor. But also we have a user who was complaining about performance issues, and I was like, “What’s your platform?” He’s like, “Well, I’ve got this little Raspberry Pi, and I’ve got this external hard drive I plugged in.”
Stephan Livera: I’m thinking, “Wow, that is like… “
Rusty Russell: It’s not even an SSD. It’s spinning rust. The Raspberry Pi has this really crappy USB port list of the three they do. So, yeah, it’s like, “Wow. Okay, so that’s as slow as you can get.” So I went out and got one, and I installed c-lightning on it because if we’ve got users who are running this, I want to make sure that it’s usable, right? You can look it up on explorers, and Raspberry Pi is the… Raspberry Pi here, it has one channel open for the moment.
Rusty Russell: So, this was exactly what was kind of the point, right? Can we get both scale up and scale down? Let’s take the Million Channels Project and put it on the crappiest hardware we can find because if your cellphone could handle a million channels on the Lightning Network, then I think we’ve certainly buried a lot of FUD about scalability in Lightning Network, right? The answer is we made it work, but we didn’t make it fast.
Rusty Russell: So, yes, it works. We got it on there. It does not run out of memory anymore. It gives you answers slowly, and it does right. You can actually use it, which is amazing, but it is not a pleasant experience, so there’s another level there. The other level is like, “Do we do all this optimization?” But then Joe comes along and goes, “Oh, cool. Here’s the 10 Million Channel Project,” or the Million Nodes Project or something and pushes the envelope again. So, we do this optimization. We end up still as slow as we are just doing 10 times as much work, or then we go, “No, a Million Channel Project’s where it’s at, and we’ll keep working on that and optimize it to the point where your cellphone will handle it comfortably.”
Rusty Russell: I don’t know. Optimization’s this thing where you can keep refining and speeding up, and you can keep doing that pretty much forever. So, at some point, you’ve got to actually ship. We got to work. We’ve got reasonably happy, and we’re done. Here are the numbers, right? They’re not pretty. It does work. It’s not fast, but it was important to us that we made some inroads on there because I think that’s… We are headed into a totally mobile world, and we’re going to need to do that.
Rusty Russell: Now, this is, of course, a full Lightning node, right? It’s not clear that your Lightning… As you mentioned, maybe you’re connecting back to up to a full node somewhere. You’re not doing all the work on your cellphone, and I think that is probably more realistic, but it’s certainly, hey, we’re geeks, right? It’s fun to go, “Can we do this?” The answer was, “Yes, we can.”
Stephan Livera: There are also some of these other ideas being thrown around on the Lightning-dev mailing list and other potential routing schemes. Did you want to touch on some of those, what are they, and what are your thoughts on those? So, I’ve seen here ant routing and some of the others. Did you want to touch on those?
Joe Netti: Yeah. This is still very experimental, but basically the idea is like, for example, these beacons for example. What if we could make a routing scheme where instead of needing the entire network graph, because that could be a lot of data. We saw that with a million channels that could be like 700 megabytes of data. Instead of doing that, what if you just have the part of the network that allows you to reach these beacons. Then if the person that you’re trying to send money to can also reach a beacon, then you could pretty much, like basically a node that you can both reach, then you can do this routing between them, and that’s a possibility.
Joe Netti: There’s other possibilities too. Then there’s also like BGP, which is the internet protocol. I don’t think that would ever work because… But there’s approaches like with BGP maybe that are ideas of how routing could work, but I don’t think that it could work with Lightning Network because it just changes too fast. You can’t store a routing table of all these routes if the network is changing so fast that all these update messages would have to be passed from the network. It just wouldn’t make any sense.
Joe Netti: There’s privacy concerns with BGP, and that leads to like ant routing. What if you just send these encrypted blobs? That’s confusing. It’s very experimental, but it’s basically like adding these extra data bits that allows you to find a route in real time by these encrypted blobs being traversed from the network. It’s cool, but it’s very, again, experimental.
Rusty Russell: Yeah, I think Joe covered that pretty well. Yeah, there are subsets of schemes where you’re like, “Well, what if we don’t have to put the whole thing? What if we can have some subset of knowledge, or you can find out?” Now, the problem is with subsets, you’re going to be less efficient, but maybe that’s okay. Who’s in the subset? Who’s in the magic group of beacons? Who becomes a beacon? Who are these landmarks that everyone uses? Because they’re going to get more payments than… Not landscapes. You have this fairness issue as well.
Rusty Russell: How do you select them? Stuff like that. There are potentially some ways around that, but other schemes where you ask for directions, and then you immediately hit privacy problems, right? You go, “How do we get a payment to Joe of 0.013 Bitcoin? What’s the cheapest way? Oh no reason. I’m just asking for a friend.” You’re obviously leaking some data there. So, there’s some things where you can combine these approaches and stuff. But what we’re doing is like the naivest… You know everything on the network. You’ve got the entire map. Go find a route, right?
Rusty Russell: But these schemes are much more like, “Okay, so if we fall off the edge of the cliff there, we go, ‘No, no. 10 million channels, way too many.  What’s our fallback?’ So there’s a whole area of research on what cool things we can do with that, which I think is interesting. Also, you look at it. You go, “Cool,” and even if you can handle it all, the one gig download to get the map on your phone. It’s pretty significant, right? That’s a big ask.
Rusty Russell: Now, we can squeeze that data down somewhat. Taproot and Schnorr actually help us a little bit. We can do some pretty cool stuff, but it’d still be that order of magnitude, right? So, it’ll be more than 100 meg of data to pull down to know the entire thing, so that you’re like, “Well, okay, maybe that’s the issue. Maybe it’s not that you can’t compute it on your cellphone.  So, yeah, there are definitely alternate approaches to how you can do things. Yeah, it is a fun area.
Joe Netti: And to add real quick, like you could even have approaches where there’s a Lightning app, and instead of finding the route yourself, you query some centralized server that has the whole map, and they find it and tell you what route to take. But then there’s privacy concerns with that, and you don’t really if they’re including their own nodes in your route to make more money and stuff like that.
Stephan Livera: They could opportunistically try and route it through their own, their mates’ channels kind of thing?
Joe Netti: Right.
Rusty Russell: Yeah, yeah. Wow, that’s expensive. What a surprise again.
Stephan Livera: So, Joe, I think you were also interested to talk about this idea of will Lightning routing inevitably become hub and spoke.
Joe Netti: Right, yeah. I mean, it might already be slowly becoming hub and spoke, but I think that really depends on what we choose the routing protocol to be in the future, and yeah, it’s really dependent on where we move forward. I mean, we can see it already a little bit with where’s the money at. Well, it’s this hockey stick and also how many channels do… Here’s an example. This is another property that I found in the snapshot of the network. If you look at… How do I explain this?
Joe Netti: Okay, so if you rank channels of a node from greatest capacity to least, you see pretty much a positive relationship between the capacity of that channel and the total capacity of all the channels of that node that that’s connected to. So, essentially what that means is that when people are… It says minus that channel’s capacity. So, basically, what this means is that when people are connecting to nodes with a lot of capacity. That’s all it means. They put more money into nodes that have more capacity, and that shows that people are doing this hub thing already. So, I don’t know. There’s a lot of question marks, but yeah.
Rusty Russell: So, just think about it like if you try to connect to Bitrefill, which is one of the big… I mean, they’re a vendor like they were fairly, as a result, naturally, they’ve become this kind of hub. But on mainnet, they won’t even talk to you unless you’ve got like 0.16 Bitcoin. It’s like you need to actually open a big channel, otherwise they won’t even let you open one.
Rusty Russell: So, they’ve actually explicitly said, “We only want big channels,” right? So that’s definitely accelerating that trend, but just as a user, you’re like, “Well, I don’t open a couple of channels.” Well, look, I’ll open up to Joe, but my main one is going to be a big one to LNBIG nodes, because they’re really well connected. They’re up all the time. Joe’s flaky. He likes to sleep and stuff like that. Turns his phone sometimes.
Joe Netti: Yes I love to sleep.
Rusty Russell: So this happens, right? So, people will naturally buy it towards that. Now, there’re a couple things that are fighting against that. We’re pushing back particularly with AMP, interestingly, so this idea that at the moment to send a big payment, you need to send it down a single channel. So payments are like these monolithic blobs, and this idea that we can split them into multiple parts and still have the properties that we want from payments. It’s really cool. There’s a couple of spec proposals that are right in the pipeline now.
Rusty Russell: I am really hoping to get it into the 0.73. release at least as an experimental feature that you can break up payments into little parts. Now, at that point, big channels are nowhere near as useful as they are today. Today, you need a big channel because you want bigger payments. You want to make a $100 payment, you’re going to need a $100 channel. Two $50 channels are not going to cut it for you. With AMP, not a problem. You split it, right? So, it reduces some of that pressure to make really big channels with big players, and it allows the network to diversify a bit more, so that’s useful as well, I think.
Rusty Russell: There’s also things like… Just naturally, we’re seeing growth of the network. So, LNBIG jumped on, so this was somebody who altruistically decided they basically wants to support infrastructure for the network because they’ve created this network of like, I don’t know, 60 nodes or something each with massive capacity that were basically all connected to each other, and you can connect into that, and you can route anywhere. They’ve been stable. They’ve been useful and everything else.
Rusty Russell: But even so, the growth of the network has dwarfed them. While they’re still there, and they’re still important, we’re not safer when you take those nodes away. We’re still good, right? So, they haven’t become… Maybe they’ve been important in the growth of the network absolutely, and they’ve pushed things up a notch, but they are grown around, which is great to see. These two factors mean that, I think, I’m reasonably confident that we’re not going to end up hub-and-spoke-y more than the power law naturally would suggest, right?
Rusty Russell: So, definitely, that property’s going to be there. There’s going to be some big ones, going to be some small ones, but I think we’re going to see the needle swing back a bit just because of the technical nature of stuff, things coming down the pipe.
Stephan Livera: Fantastic. Let’s talk now about the results of the Million Channel Project. So, maybe, Joe, you can tell us a little bit about the final. What was the simulated size in terms of nodes and channels and so on.
Joe Netti: First off, one of the big results is that we optimized c-lightning. I mean, Rusty did optimised c-lightning like crazy. If you look at the blog post, there’s a nice graph that shows… the before and after of some calls, API calls, and then shortest path, and Rusty optimized it crazy. Then also, I’m trying to pull up here the… Okay, yep, simulated size. So, we got close to a million channels. It’s like 998,000 channels, 94,000 nodes, and the gossip was 731 megabytes, and then the total Bitcoin, except this is scaled down. This is actually scaled down and regtest, but the total Bitcoin is 17,300, fake Bitcoin, of course. I wish I had that much. But yeah, that’s basically the end result of that.
Rusty Russell: Yeah, it’s interesting. Less than 100,000 nodes making those million channels, out of which, 20,000 were just one channel, right? So that power law again. A fifth of the nodes only had one channel. But then there are the whales who made up for it.
Joe Netti: Yeah, and that matches what we see right now, so that’s why it’s like that.
Stephan Livera: Yeah, so in terms of making it work on the RasPi 3, what was required there?
Rusty Russell: Other than going to buy myself a Raspberry Pi and hooking it up, which is always fun. The main thing is that it’s memory-constrained, right? So, it has two gigabytes, so you could give it some swap, but even so, right? Just keeping the whole million channels in memory was originally… Space wasn’t something that we’d really optimized for, and originally, we basically pulled that 731 megabytes, that whole store of all gossip we’ve ever received. We would just pull that all into memory and leave it there rather leave it on disk.
Rusty Russell: So, immediately, what happened is my RasPi ran out of memory, and it crashed badly. So, there’re a couple things here. One is like, “Okay, well, you should give it some meaningful message when it runs out of memory. There should be something said rather than just dying randomly.” So, there are some fix-ups in that. But the other thing is even if you ask them to list all the channels, we have a good old tool that you can use to talk to c-lightning, and you go, “Okay, cool. Give me the channel list,” right? It was speaking back a million channels except it was two billion because it prints out… Each direction is like a separate half. So, it’s this massive fire hose.
Rusty Russell: Then that tool would crash because it would try to load up. It would basically take a response, try to format it all for you, but it couldn’t even fit in memory, right? So, all these things are making it more graceful with handling these kind of things that we never hit in real life yet, but inevitably we will. A lot of it was just shrinking things down to fit inside the Raspberry Pi. We’ve done a lot of optimization already, but my laptop has eight gig of RAM. It had no problems. You shrink down to these little machines, and you go, “Okay, well, we’re going to have to actually squeeze things here as well.”
Rusty Russell: So, there’s another round of optimization just to get it to run at all in that environment. So, yeah, a lot of cool stuff came out of that. We now keep the gossip on disk, and we just basically hand around, “Here’s where it is. You can go get it yourself.” We used to have this gossip daemon that took care of all the gossip. So, when someone connected in, and they want to know something, the little daemon would talk to them, would talk to the gossip daemon. It’d go cool this is what they want to know, and we shuffle this data back and forth.
Rusty Russell: We went, “Well, actually, now, we’re putting it all on disk, let’s have the daemon just look at the disk itself, grab that the file and just start spreading it out,” and that’s actually a huge win itself both because now we don’t have all this memory. No one’s loading up and keeping it in memory, but also just the speed, the scalability that we can do with that is actually pretty nice. So, that work went in.
Rusty Russell: While it makes it work on the Raspberry Pi, it lifted everything across the board, right? It makes it faster on my sample nodes and stuff like that. The other thing that c-lightning does really badly is that it’s really chatty. It used to be up until the latest release. Every time we connect to someone, it said, “Cool. Give us all the gossip. Tell us everything,” right? It works. You never miss anything, but basically you ask for this fire hose every time.
Rusty Russell: So when your node restarts, and you’ve got 100 channels, tell me everything you know, and there would be a lot of stress at that point on this central daemon to digest all this stuff. God forbid, you’re talking another c-lightning node because it would also ask you, “Can you please tell me everything you know,” and we would then just feed it everything.
Rusty Russell: So, in the last release we got a little bit smarter with that. Obviously, if we’re up to date within the last 24 hours, we go cool, just give us the last 24 hours, and we asked that from a handful of nodes like we’ll ask for eight, and beyond that we just don’t worry at all. We have come this high, medium, low. Actually, sorry. It’s three nodes. We asked for it. You give me everything in the last 24 hours. We go “cool”. You just gave me everything from now, and if we’ve got more than a week, the rest of it just don’t tell me any gossip. I’ve got enough gossip.
Rusty Russell: If we detect something weird, we go, “Hold on. We didn’t know about that channel when we should have.” Then we go back and we pick someone randomly and we go cool, and you tell me everything, and we go back and grab the law, but that’s just way friendlier on the network as a whole. But I didn’t want to do that before I did the million channels optimization because the fact that we were so dumb about it stretched this stuff really nicely.
Rusty Russell: I want to make it fast, make it work. We actually uncovered a bug in lnd’s implementation because my node was so slow because I run with a whole deal of extra debugging checks that when we ask them to connect the channel, we were also asking for all the gossip. We didn’t get their message, their reply through all the gossip that they were sending us until it was too late. It would time out on us. So, we uncovered a number of bugs with the way we handle gossip.
Rusty Russell: So, yeah, there’s been a whole heap of work on this, and again, this is an ongoing thing. There will be more gossip optimizations coming in 0.7.3, so it does keep us ahead. Every so often, you go back to Million Channels Project and go, “Okay, so how are we performing today?” We don’t keep measuring this stuff. Inevitably, you put some things in. You didn’t realize how bad it is going to effect them in channel’s case. So, we tightened the screws once. You do have to go back and check every so often that you keep yourself honest.
Stephan Livera: Excellent. Let’s talk a bit about ideas for future work. Maybe, Joe, did you want to touch on if there’s any ideas on what could be a good project or good ideas to look out for next time?
Joe Netti: Yeah, so the Million Channels Project can always be expanded. For example, the properties of the Lightning Network, like the power law distribution, stuff like that. They weren’t really that important in optimizing c-lightning. They weren’t really that used that much, but they would be important if we are testing different routing protocols. So, there could be a way to use the Million Channels Project to compare different routing protocols and see which one fares better, and then it’s really important if we have an accurate topology and an accurate channel capacities. So, that’s interesting.
Rusty Russell: Yeah, so I’m interested to see how well it tracks, like as we do get to a million channels, how accurate was this simulation? I mean, we obviously extrapolated, right?
Joe Netti: Right, exactly. Yeah.
Rusty Russell: There’ll probably be changes. It’ll be really interesting to see the real Million Channels Project, where like now, it really is a million channels. How close did we get, right?
Joe Netti: Yeah, that’d be really cool too. This is cool too. I didn’t mention this, but I compared the actual Lightning Network in January to the actual Lightning Network in May, and it does the properties that I grabbed out of it still hold. They held in the data in January and the data in May. That’s pretty cool. So, maybe they’ll keep holding. I don’t know.
Stephan Livera: Also, Joe, I think you were chatting before. You had a few thoughts around the micro and macro purposes of Bitcoin and economics. What were your thoughts there?
Joe Netti: Yeah, I have a side hobby or passion of economics. You can see in the Million Channels Project, but I know that a lot of your listeners are Austrian based, so that’s why I wanted to talk about economics a little bit. I split economics into macro and micro like most economists do, but I define it a little bit differently, and I view the purpose of micro as guiding rational action towards some goal for individuals and for companies. So, for example, that’s game theory, like utility functions, stuff like that.
Joe Netti: Then I view macro as predicting or forecasting the future changes in economic outcomes based on changes in policy and changes in technology, et cetera. So that includes econometrics. That includes, I would even say, a little bit of behavioral econ because you got to know how people are actually going to react to a certain policy in the real world of biases and stuff. This is a recent discovery, like basically, micro is for guiding individual action. Macro is for forecasting, and I think that’s pretty cool.
Stephan Livera: Right, okay. Yeah, so I mean, for me, I think it’s… I guess comparing against an Austrian framework, it’s like we’re thinking more about the decisions that are made by individuals, and then in a macro sense it’s like what are the impacts that that has at this. If you’re considering what all these different individuals are doing, what’s the impact that that does to the broader world and the broader economy?
Joe Netti: Exactly, right.
Stephan Livera: But yeah, thanks for sharing that. Rusty, I’d be also interested just to discuss if you’ve got anything you wanted to share around what’s coming with c-lightning in the new version.
Rusty Russell: Oh, yeah. So, always, always heaps of stuff. There’s inevitable bug fixes and optimizations and stuff. We’ve had a lot of excitement around plugins. So, the idea with c-lightning is basically we want to build this space. We want to build a really solid implementation that does all the things we expect from a node, particularly aiming at the server side, right? So that’s my background. It’s Blockstream’s interest.
Rusty Russell: You want to set up a store that accepts Lightning. Okay, so this is the kind of infrastructure you want, but there’s a whole other really cool stuff we want to build on top, and we went, “Well, these ideas started coming out if you want to do it.” We’re like, “We really don’t want that in our code base. It’s kind of boutique to these people. It’s really cool. We’re not sure, people use it, we’d have to support it and everything else.”
Rusty Russell: So, we ended coming with this plugin idea where basically people write plugins the same way they write plugins for web browsers and stuff to do ad blocking or turn the screen upside down and stuff. So, c-lightning has been really aggressive doing a lot of infrastructure work to grow that plugin infrastructure, so that plugins can do more and more invasive and interesting stuff. With each release, we see more capability built for plugins, and the plugins also lag a bit because someone actually has to then go and use them.
Rusty Russell: We’ve got a database hook that went in the last release, which means that you can do live backups. So, if you want to do multi-site backups for your c-lightning node, which is important because obviously there’s real money involved if you want to… Backups are important. Don’t be like me. Back up your stuff. I have a test node that’s completely not backed up that I use for test payments. But in some of this robust scenario, you’re going to be doing backups. You want backups across multiple sites in real time and stuff like that.
Rusty Russell: So, now, there’s that infrastructure that goes in, but there’s also some really cool infrastructure for expanding things and doing experimental things. The other thing that we’re seeing come through is we had this big spec meeting in Adelaide in November of last year, and we drew a roadmap of what’s going to be involved in 1.1, or maybe I might even call It 2.0, a Lightning spec. Everyone came in with all these ideas, and we fleshed out this rough map of stuff that definitely should be in 1.1.
Rusty Russell: Now, we’re going through the phase of actually doing the hard work of writing it all down, specing it all out, writing test vectors, making sure everyone’s on the same page and all the details. A lot of bikeshedding, a lot of finagling the details, but that’s really started to come to a head now. A lot of stuff’s getting agreed. People got distracted. There’s so much stuff to work on outside this even just in the 1.0 spec. So, just recently in the last few meetings… We have a meeting every couple of weeks. We’ve had sort of the floodgates and a whole heap of stuff go in, so you’ll see excitement ramp up in implementations as well as they start to implement these features.
Rusty Russell: I talked about AMP, for example, a multi-part payment idea. That is definitely something that I want to get back to. We’ve got a spec proposal out. We want to implement it. The rule is that you’ve got to have two implementations that can interoperate before it can go into the spec, finally, right? We approve it, like we had some good idea, but it’s pending testing, and it takes two people. Separate people have to implement it, make sure they work together, and then we can like go, “Cool,” and that’s saved us a number of times just because you’ve got to implement your wow.
Rusty Russell: If we chose this way instead of that way, this would be so much easier. So, that’s the way things go forward, and we’re going to see that in the implementations in the next few months as we ramp up. We also have the Lightning Conference, so there’s this conference. It’s really a Lightning developer conference. So, previously, we’ve had these summits, which are about developing the Lightning spec, right? The protocol, and we get into deep in the weeds of actually how Lightning implementations work. So people who write Lightning implementations there.
Rusty Russell: The Lightning Conference is more like people using Lightning. Developers one layer up are using Lightning to build their stuff and do cool things on top of that, and there’s a great community of Lightning makers out there. There have been meetups and everything, and we thought, “It’s time take it to the next level.” So, all the teams are basically going to be in Berlin at the Lightning Conference, thelightningconference.com. I’m really excited about that because that’s always fun, right?
Rusty Russell: You meet a lot of people doing really interesting things with Lightning, but also all the devs are going to be there. It’s going to be like an ad-hoc spec meeting. We’re going to thrash out all this stuff. So, yeah, and Berlin’s always a fun city, so that’s coming up as well. Inevitably, that will change like it’ll be before and after that meeting. There’ll probably be some stuff come out of that that will completely change our priorities, right?
Rusty Russell: People might say, “Wow. This is really important,” and be like, “We didn’t even think of that.” That happens always when we talk to users about their pain points and things. So, I’m really looking forward to that experience, and that’s definitely going to accelerate things. Just generally, this whole ecosystem is snowballing. So, on the one hand, it’s frustratingly slow. On the other hand, it’s day to day, and it is really exciting because stuff happens all the time.
Rusty Russell: But when you think about it, we’re basically trying to build a whole new industry here, right? There’s no micropayment industry because there are no micropayments in the world. We don’t have the ability to send one cent around the world until Lightning, so we’ve built this thing, and it takes time for people to… Maybe there was someone out there who had this fantastic idea five years ago, but they couldn’t do it because they couldn’t send one cent. It didn’t make sense. They would skirt it, right?
Rusty Russell: It takes time for those ideas to converge and to get those ideas and be like, “Hey, cool. We can actually do this now. We’ve got the capability. We’ve got this instantly settled, transferable, of value, of small amounts, really cheaply. What can we do with that now?” This industry will take… I mean, this is a long process to build a whole new industry around this, but it’s definitely happening, and that’s exciting to me, and that is definitely going to continue, and I expect we’ll see this kind of like… This slow, steady technical growth.
Rusty Russell: But then at some point, it kicks up where it says there’s some ridiculous killer app. There’s probably something that Stephan and I will sit here and go, “That is the stupidest idea ever,” right? But it’ll be amazingly successful. They’ll be flying corporate jets and stuff.
Joe Netti: hHshtag CryptoKitties.
Rusty Russell: Yeah, right. It will be something that kids are into these days, and we’ll be sitting there going, “But that’s just the dumbest thing I’ve ever heard,” right? So, there’ll be something. There’ll be some killer app at some point, and in retrospect, it’ll be obvious. But from this point of view, it’s totally not, and I’m definitely looking forward to seeing that happening, but you can’t control the timeline on these things. You’ve got to have the infrastructure ready. You’ve got to have all the capability. You’ve got to have the experience.
Rusty Russell: People are getting accustomed to how these things work and building all these examples and doing some real stuff on it, and that infrastructure is basically is required before you can have that amazing growth on top of it. So, we’re still in that early infrastructure days, and while it’s exciting for those inside of it, it hasn’t really got outside that bubble even though the bubble is growing. At some point, I expect it will explode on the world stage, and suddenly people will be like, “Wow,” and I’ll be like, “I’ve been working on this stuff for years now.”
Rusty Russell: They’ll be like, “No. It’s only been like two weeks ago.” I’m, “No. Actually, we worked on this for a while.” So, that’s definitely something to look forward to if you look further, but making solid predictions about it is impossible.
Stephan Livera: Yeah, look that’s great. I think that’s pretty much all I was going to touch on for this episode. So, thank you both for joining me, and look, before we let you go, let’s hear from both of you on where the listeners can find you and follow your work. So, Joe, let’s start with you. Where can the listeners find you?
Joe Netti: Sure. I’m on Twitter with Joe Netti. J-O-E. N-E-T-T-I. Also, on GitHub, nettijoe96, and that’s it. That’s about it.
Stephan Livera: Great. And Rusty, as for you?
Rusty Russell: Yeah, so, rustyrussell on GitHub, and @rusty_twit on Twitter, but Google will find me as well. So, it’s pretty easy. Always like hearing from people too, so reach out.
Stephan Livera: Fantastic, and I’ll obviously put the link to The Million Channel blog post as well in the show notes. So, look, Rusty and Joe, thank you both for joining me today.
Joe Netti: Thank you for having me on.
Rusty Russell: Thanks, Stephan.


Pretzel and Hotdog have lived their whole life in a cart. They decided to escape when their friend got sold
On their adventure they came across a log with an ant. They became friends.
they continued down the park road and came across a rock. Flying around the rock was a bee. The bee then joined them on their journey.
The four new friends all continued down the path. After a few minutes they came across a leaf with a small snail. They started talking and the snail joined their group.
After a little bit of time Pretzel noticed a figure that looked like him. They looked a little closer and realized infront of them was a group of hotdogs and pretzels just like them.
They all became friends and decided to start a town so they could all live happily, freely, and safely. And that's what they did.
The new family is still living in their town peacefully and they will continue to live there forever. THE END!


MIAMI BLUES A film review by Shane R. Burridge Copyright 1996 Shane R. Burridge
(1990) 97m.
In George Armitage's adaptation of Charles Willeford's novel, Alec Baldwin plays a wanted ex-con whose devil-may-care attitude surprisingly hasn't yet led to his capture. Upon reaching Miami he meets up with ingenue hooker Jennifer Jason Leigh, adopts her as his fiancee, and sets about supplementing their income with a string of petty thefts. Upon acquiring the cuffs, badge, and other accouterments of cop Fred Ward, he discovers that larceny has never been easier. Disarming black comedy-drama stands out among others in the pack because its offbeat plot turns make it hard for the viewer to match a rhythm to it. The sex scene we all expect comes earlier than expected, the initial meeting between Baldwin and Ward isn't how we anticipate it, and Baldwin, the prime proponent of the film's randomness, does not move to a predictable plan - he is psychotic enough to kill on a whim, yet never rises above purse-snatching and break-ins. What's interesting is that while Baldwin is the cause of so much random violence towards others, he is at the same time the victim of spontaneous, violent acts.  It's an appropriate nickname, and Leigh is a suitably ditzy companion for him.
In one picture-postcard scene, Baldwin and Leigh watch couples happily playing with a frisbee against a Miami beach sunset. No sooner have the two of them set up house than they are playing with a frisbee outside on the front lawn. When Leigh, with an older and wiser glint in her eye, tosses the frisbee aside at the film's conclusion, she, for one, knows that the dream is over. Unlike Junior, Ward, world-weary and only one week from retirement, manages to finish what he started. Ward and his world are mundane and orderly, and the antithesis of Baldwin, a character out of sync in a world out of sync. While convention dictates that the cop and his quarry remain separate for the bulk of the film we nevertheless feel a connection between them.  Baldwin's character is always interesting (how many films have you seen where the criminal accompanies a house burglary with an improvisational haiku?), Leigh somehow manages to play superficiality with a sense of depth, and Ward fits into his role effortlessly. Weird coincidence: Baldwin steals a badge and passes himself off as "Sergeant Mosely". Two years earlier in MIDNIGHT RUN, Robert De Niro steals a badge as passes himself off as "Agent Mosely". Has anybody else noticed this?
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


One of the surprising things about getting QA teams started with automated testing using BDD is how flexible it can be. You can get started on a basic framework even if you have minimal user and developer support.
Of course it is better if other roles are involved at a frameworks inception but that shouldn’t necessarily be a barrier to it happening at all.
Choosing a Testing Tool
I have used various agile testing tools, but the best was Cucumber. It is important to remember that cucumber isn’t a automated testing tool itself, it is a parsing tool for linking requirements written in a business domain language to the tools that implement the test. I’ll write a blog somewhere else why this a good thing and we shouldn’t just code automated tests directly.
Cucumber can be used with various other technologies including WATIR (a collection of Ruby libraries providing an API for working with browsers), Java, Ruby… The most successful implementation I have worked on was Cucumber with the implementation layer written in Ruby with Selenium (providing interaction with chrome and Firefox) and Capybara. Capybara help implements with BDD paradigm and speeds up greatly the coding process. It even allows people with less technical skills to write some of the more simple acceptance tests.
This sets up the context for what a few of the blog posts that follow. I’ll cover how to implement this framework for a fictional website and how some of the aspects of BDD can work from my experience.


This past weekend I started really digging into Ruby on Rails. For a while now, I have known a little bit of ruby (by reading Why's Poignant Guide and messing around a little with Rails), however, I wanted to have a much stronger understanding in it – even if it's only for the concepts.
Why Rails – Why Now?
Rails has been publicly available since July 2004; some may ask why I am just now becoming interested in the framework. There are actually several main reasons…
- It is a good educational resource in the MVC Pattern. This applies to many implementations such as Microsoft MVC, Symfony and Cake on PHP and a whole slew of other frameworks.
- Rails is becoming a more viable option with JRuby and the forthcoming releases of IronRuby.
- The concept of DB Migrations is very nice – especially when you have encountered the difficulty involved in placing your database under source control.
 NetBeans seemed like a good idea to me because of the simple JRuby integration (other options Aptana Studio, Eclipse, your favorite text editor w/ Instant rails).
-
Created a series of databases (as needed) for the various test rails apps to write to.
-
Downloaded and installed MySqlYog Community edition. I knew I was going to be handling most of my database stuff with the Rails ActiveRecord implementation and db migrations BUT I still wanted to see what was going on inside the db.
Initial Impressions
After the initial hour or so of setting up my environment, I wrote some quick test applications (following some tutorials, at first obviously). I really liked the principle of Convention over Configuration. This was apparent in many areas of the framework such as the generator / rake tools and the easy application configuration in the .yaml files. I can see how this may not be the best choice for certain applications but for a lot of web applications, it seems like it will be a good fit.


TRAIN SCHEDULE OPTIMIZER
Dynamically Updated Arrival and Departure Times
For Any Train*
(*
You Can Imagine
)
Current Trains
Train Name
Destination
Frequency
Next Arrival
Minutes Away
Add New Train
Train Name
Destination
Time of First Train (military time)
Frequency (minutes)
Submit


| No | Name | Description |
|---|---|---|
| 1. | Zawgyi | Zawgyi One is not an input method but just a font. Modern Burmese keyboards allow natural typing order for both Unicode and Zawgyi outputs. Some people still think that Unicode is harder to type. The numeric codes used in Zawgyi are not the same as in the Unicode Standard. |
| 2. | Unicode | Unicode is a computing industry standard for the consistent encoding, representation, and handling of text expressed in most of the world's writing systems. The standard is maintained by the Unicode Consortium, and as of june 2018 the most recent version, Unicode 11.0, contains a repertoire of 137,439 characters covering 146 modern and historic scripts, as well as multiple symbol sets and emoji. |
| 3. | Win | Win Myanmar Systems, better known as Win Myanmar Fonts, translates MS windows menu to Burmese. The Win Myanmar font system for Microsoft Windows is common in Myanmar for digitally processing Burmese script. |


I am Michael Kipchumba, a designer based in Kenya. I create User Interfaces for web and mobile, plus identity designs. I like coffee, playing guitar, comics and film.


Listed are all of the products currently available on our website.
THIS IS A GREAT OPTION FOR ANYONE JUST TRYING OUT OUR BEER!

THE SUPERIOR OPTION! SIX BOTTLES OF BANDAID BEER! WHAT MORE COULD YOU ASK FOR?


Bitgoldcoin is a peer-to-peer Internet
currency that enables instant, near-zero
cost payments to anyone in the world.
Bitgoldcoin is an open source,
global payment network that is fully
decentralized without any central
authorities.
Bitgoldcoin is an open source
software project
released under
the MIT/X11 license...
The Bitgoldcoin blockchain
is capable of
handling higher
transaction volume than its ...
Wallet encryption allows you to
secure your wallet,
so that you can
view transactions and your account...
Miners are currently awarded with 100
new bitgoldcoins
per block, an amount
which gets halved roughly...


Features
ChamosBot is a Discord bot focused on providing Hypixel stats to its users. Currently, it supports Bedwars, SkyWars, and the Pit, with Bedwars having the most features at the moment. ChamosBot also integrates with a web app that displays Bedwars stats over time.Technology
ChamosBot is written in Python using Discord.py, and is currently running on one of my Raspberry Pi 3 B+'s. I've thought about moving it to the cloud on an AWS virtual machine, but for the time being I'm keeping it on my simple machine because it doesn't serve very many servers. The data is fetched using the Hypixel API. When you add it to your Discord server, you provide it with your Hypixel API key.If any of this sounds complicated, don't worry!  Setting up the bot is super simple.
Features
Check out the Bot's commands, the web app run-down, and more!Commands
-
{% for command in commands %}
- {{ command.icon }} {{ command.prefix }} {{ command.description }} Command reference {% endfor %}
Every command is handled by ChamosBot. If you have any issues, first make sure the bot is online. If the bot is offline, it is very possible that the Raspberry Pi ChamosBot runs on crashed or got disconnected from the network. In this case, I will know, and there isn't really a need for a bug report. If the bot is online and it is not responding to commands, sending strange responses, or misbehaving in any way, feel free to make a bug report at the GitHub page.
Web App Info
The web app is currently only for select test users. If you want a preview, you can check out my stats.
Web App
To view Bedwars stats over time, enter each Minecraft username that you would like to get stats for below. Separate each name with a space. Then, select how much stat history you want to view.
Please note that this feature is very limited, and is only available for a small set of usernames. It is likely that your username does not have data saved.
Please note that this feature is very limited, and is only available for a small set of usernames. It is likely that your username does not have data saved.
{% for statfile in statfiles %}
{{ statfile.display }}
{% endfor %}
Free Vector


No e-cigarette, vape registered as smoking cessation tool, says deputy minister
KUALA LUMPUR, Nov 12 — Currently, there is no electronic cigarette (e-cigarette) or vape has been registered as smoking cessation tool or medication, said Deputy Health Minister Dr Lee Boon Chye.
However, he said, the vape liquid containing nicotine was regulated by the Ministry of Health under the Poisons Act 1952 and any sale of the product could only be done by licensed pharmacists and registered medical practitioners for medical purposes.
He said individuals who were not among the licensed professionals, could be fined of not more than RM3,000 or imprisonment not exceeding one year or both, if found guilty of selling products containing nicotine.
“Hence, after the seizure, an analysis will be carried out and if nicotine is present in the vape liquid, action will be taken against those found selling vape containing nicotine,” he said when winding up the debate on the Supply Bill 2020 for his ministry in the Dewan Rakyat sitting today.
Meanwhile, Dr Lee said the ministry had met with vape industry players for feedback before any decision to be made, either to ban the use of vape, or to impose stricter restrictions on sales of vape liquid.
“We also invite the industry to present its working paper for consideration by a special committee (on methods to control the use of electronic cigarettes or vape) before the decision will be made,” he said.
The Dewan Rakyat sitting continues tomorrow. — Bernama


Pairing and Feedback
July 15, 2015
It's fun to pair with others on challenges. You get to know another person's thinking style, and their knowledge and different way of approaching things helps you learn. Sometimes I get stressed out about scheduling pairing sessions, especially when I'm traveling and have small timeframes and an uncertain schedule, but once I sit down to start a pairing session with someone all of that stress vanishes and we get absorbed in the problem at hand. I love it when a breakthrough comes after we've been slogging away at a problem, or when something one of us suggests suddenly expands our knowledge of Ruby.
I found a pattern in the constructive criticism in my feedback, which was that I tend to jump in and start experimenting when faced with a challenge, and might not always take the time to explain myself well enough to my partner. I know I do this, and the VARK personality test confirmed this trait by indicating that I'm a concrete random thinker. I would definitely benefit from slowing down and mapping out a solution to the problem beforehand, as my partners suggested. After receiving this feedback, I've been taking my psuedocode more seriously and trying to spend more time thinking through each step of the process before going off to research methods to help. I'm also trying to work on verbalizing my thought process, so I don't lose my partners in my rush to get things done.
I like giving positive feedback to partners, but it's often hard for me to come up with constructive criticism that's specific and actionable. I usually want to praise the person, say the pairing session went well, and say keep doing what you're doing, but that's not as helpful as something that at least attempts to point out a weak spot. When I step back to think about what they could improve upon, it sometimes surprises me with what I come up with. I realize that they could do more research on methods, or articulate their thought process more clearly, or something like that which I had overlooked before. I think that sometimes when I like people, I suppress critical thoughts, but those observations are actually useful if they are brought into the open and articulated kindly.
The process of giving and receiving feedback is helping me improve on my coding, but it's also helping me learn how to be more honest with myself and others.


Please Complete The Form
Holder Name:{{userDetail.firstName+" "+userDetail.lastname }}
Card Number :{{userDetail.cardDetails.cardNumber}}
Card Exp Date:{{userDetail.cardDetails.expDate| date}}


Welcome
Jan 31, 2015
What’s This App Changed My Life
?
This is a website dedicated to Apps that have changed the way we function and behave, for better and for worse.
What’s This App Changed My Life
?
This is a website dedicated to Apps that have changed the way we function and behave, for better and for worse.


--- layout: post title: Openbaar date: '2016-12-13T10:11:18+01:00' categories: - Ello Mobile - Sketches picture_url: https://film-Storyboards.tumblr.com/post/154424579726 ---
Pushing the envelope.


Due to enormous amount of data present in a web application or shopping carts, recommendations are used to engage users and helps in saving good amount of time to look for similar products which were interested by them. Moreover, Recommender systems helps in maximizing the profits of an organization by suggesting relevant items which might be purchased by the user.
Our project aims to build a recommender system for the given data set using user behavior learning. Collaborative filtering technique is one such method used to display recommendations using user input. Recommender systems play a major role in increasing user interaction with applications by recommending useful items to the user based on the previous history.
Data set has a major role to play in building recommender systems. Data set shouldn’t contain null or empty tuples. For this project we are using beer review data from social website (Beer Advocate). This data set has ratings for each beer in different aspects such as aroma, appearance, taste, palate & overall rating with 1,586,614 records.
For this recommender system we are using Matrix factorization method with stochastic gradient. The model is used to estimate matrix which approximates to rating matrix (input to the model).
R is the rating matrix (This matrix is formed when the user inputs the preferences).
P is a latent feature matrix of the user and features (aroma, taste, appearance, palate, overall rating).
Q is latent feature matrix of Beers and features.
R` is built with matrix factorization.
Item -Item collaborative filtering is one such recommendation techniques used to recommend items similar to those which were rated by the user or interested by the user in the past. This method is similar to the user-user collaborative filtering technique where the similarity between items is measured and predictions were made to those items for a particular user and analyze whether he is interested .
• The above shows some probable scenarios for user input preferences. Then the overall weighted sum of rating is calculated using the below method: Overall weighted rating (for case1)= (2*(review_overall)+2*(review_taste)+1*(review_appearance)+1*(review_aroma)+2*(review_palate))/2+2+1+1+2
here {i= 1,2,3,....n} which is user's who rated both A and B
Here S is the similarity score of Item u with item N
R is the rating given by the user u for item N
N can be subset of items which have some similarity score with respect to item i
1. Item-Item recommendations: For user 'northyorksammy' with the weights 1 1 1 1 :
User-User Recommendations:
2. Item-Item recommendations: For user 'mikesgroove' with the weights 1 1 1 1 :
User-User Recommendations:
As seen in the above comparison results, The recommendations from these two models have no or very few matches. This mainly has to do with the way these models are designed and the factors that are taken into consideration to give recommendations.


I want to preface this post by saying that in my perfect world, we wouldn’t grade at all. But currently, that isn’t my reality. I will continue to do the best I can with the rules and requirements placed on me.
We have progress reports coming up this week and as I was sitting and staring at my spreadsheet, I began to think about grading again. Let’s get deep.
One thing I love about my teaching is that I’m committed to Standards Based Grading as part of my Flipped Learning implementation. It communicates ideas and progress much more clearly than traditional grading practices do.
Essentially, there are two kinds of students in my class: those with an A and those with an F. Now, without getting too political about grades, I want to say that I really like the way my book plays out. Here’s why.
First, I don’t have to rationalize all of those middle areas.  It is a binary system (for me, at least)…you know it, or you don’t. Therefore, any student who can demonstrate their understanding of a concept automatically is marked with a 100%.
Second, as the teacher, I do not feel like I have the right to assign a letter that describes a student’s learning other than a simple yes or no. I want my students to be able to explain the nuances of their learning, not hear it from me. This happens with reflection and discussion as we go through the problem-solving and application process in class.
 I’d rather not focus on grades at all. When I’m constantly hunting for points for students (“Why did I get an 18 instead of a 19?”), I cannot focus on supporting their learning. The student is also not focusing on learning. Grading with a binary system helps keep the conversation on skills and demonstration, not completion for points.
Finally, the conversation about grades changes with parents. We don’t discuss which assignments their child can turn in to improve their grade. We can focus on what learning strategies might work best for their son or daughter. School becomes a place where teachers are supporting learning rather than just somewhere to go and work for the day.
How do your grades communicate learning to parents? I’d love to hear more examples in the comments.
Written on December 3rd , 2012 by Brian Bennett Categorized in: All
Leave a comment


#include <Connection.hpp>
| Connection::Connection |
( |
| ) |
|
| Connection::~Connection |
( |
| ) |
|
| void Connection::broadcast_packet |
( |
void * |
data, |
|
|
int |
size |
|
) |
| |
| bool Connection::create_client |
( |
std::string |
ip, |
|
|
int |
port |
|
) |
| |
| void Connection::create_server |
( |
int |
port, |
|
|
int |
num_peers |
|
) |
| |
| int Connection::event_service |
( |
int |
timer | ) |
|
| bool Connection::event_type_connect |
( |
| ) |
|
| bool Connection::event_type_disconnect |
( |
| ) |
|
| bool Connection::event_type_receive |
( |
| ) |
|
| ENetAddress Connection::getLastConnection |
( |
| ) |
|
|
inline |
| void* Connection::getPacketData |
( |
| ) |
|
|
inline |
| unsigned int Connection::getPacketLength |
( |
| ) |
|
|
inline |
| int Connection::getPeerId |
( |
| ) |
|
|
inline |
| void Connection::send_flush |
( |
| ) |
|
| void Connection::send_packet_reliable |
( |
void * |
data, |
|
|
int |
size, |
|
|
int |
ID |
|
) |
| |
| void Connection::send_packet_unreliable |
( |
void * |
data, |
|
|
int |
size, |
|
|
int |
ID |
|
) |
| |
The documentation for this class was generated from the following files:


Find the first file matching a given pattern in the current directory or the nearest ancestor directory.
Matching is done with micromatch, please report any matching related issues on that repository.
npm i findup-sync --save
var findup = require('findup-sync');
findup(patternOrPatterns [, micromatchOptions]);
// Start looking in the CWD.
var filepath1 = findup('{a,b}*.txt');
// Start looking somewhere else, and ignore case (probably a good idea).
var filepath2 = findup('{a,b}*.txt', {cwd: '/some/path', nocase: true});
patterns
{String|Array}: Glob pattern(s) or file path(s) to match against.options
{Object}: Options to pass to micromatch. Note that if you want to start in a different directory than the current working directory, specify a cwd
property here.returns
{String}: Returns the first matching file.Install dev dependencies:
npm i -d && npm test
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt
For bugs and feature requests, please create an issue.
2017-08-07 - v2.0.0 - Drop node 0.8 support, Bump all dependencies (including some Majors)
2017-04-18 - v1.0.0 - Major bump from stable 0.4.3
2015-01-30 - v0.4.0 - Refactored, not also uses micromatch instead of minimatch.
2015-09-14 - v0.3.0 - updated glob to ~5.0.
2014-12-17 - v0.2.1 - Updated to glob 4.3.
2014-12-16 - v0.2.0 - Removed lodash, updated to glob 4.x.
2014-03-14 - v0.1.3 - Updated dependencies.
2013-03-08 - v0.1.2 - Updated dependencies. Fixed a Node 0.9.x bug. Updated unit tests to work cross-platform.
2012-11-15 - v0.1.1 - Now works without an options object.
2012-11-01 - v0.1.0 - Initial release.
"Cowboy" Ben Alman
Copyright (c) 2012-2016 "Cowboy" Ben Alman
Released under the MIT license


---
layout: post
title: Disappointed by the ice that kept me from biking to work this morning.
published: true
date: 2009-01-05
categories: []
posterous_url: http://verdammelt.posterous.com/disappointed-by-the-ice-that-k
posterous_slug: disappointed-by-the-ice-that-k
---
It was a skating rink all the way up to Central Square. Luckily we
caught a bus a few blocks from the house.
I was hoping that today would be my first bike commute of the New
Year. I want to ride much more this year so i can't use cold weather
as an excuse.  Lucky him.