HN user
continuously monitoring the estimated model performance
Main point here. Model performance can degrade for any number of reasons and at varying rates. As a starting point, focus on setting up anomaly monitoring for a robust set of model eval metrics tailored to your task: loss, calibration, model staleness, etc. Timely alerts can give you sufficient time to dig in and root cause, roll back a model, etc.
Recently listened to this on a road trip and I can report that it kept me interested and awake :). This podcast quickly focuses in on the problem of boolean satisfiability and the history of SAT solvers for those unfamiliar with said topics.
In theory, this benefits complex business processes running across corporations/agencies/gov/etc. requiring a distributed ledger. For example, mineral mining/procurement/certification/etc is a complicated lifecycle across many actors. I can't remember which podcast I heard it on, but the suggestion was anywhere there was a "clearing house" in use by multiple corporations for a particular process, there was an opportunity for blockchain/smart contract use.
In practice, I have yet to see anything concrete, but I haven't exactly been looking hard.
I don't recall Task Roles being a thing when I started using EC2 Container Service. For container security and isolation, that makes a whole lot of sense.
Having built something similar with RabbitMQ in a high-volume industry, there are a lot of benefits people in this thread seem to be glossing over and are instead debating semantics. Yes, this is not "exactly once" -- there really is no such thing in a distributed system. The best you can hope for is that your edge consumers are idempotent.
There is a lot of value derived from de-duping near ingress of a heavy stream such as this. You're saving downstream consumers time (money) and potential headaches. You may be in an industry where duplicates can be handled by a legacy system, but it takes 5-10 minutes of manual checks and corrections by support staff. That was my exact use case and I can't count the number of times we were thankful our de-duping handled "most" cases.
Instances get role data from the metadata service, but containers can't access that metadata and should access the local ECS agent instead (which has its own API).
Just a quick aside, but is this can't or shouldn't? I'm 100% positive you can use something like instance profile credentials from within a container (which loads credentials from the instance metadata service).
I think I agree that there's definitely a lot of depth to topics that should be covered here, and whether you want to go down the rabbit hole will vary based on org size and features you're using.
I'd personally prefer: 1. deep-dives into best practices for each feature as opposed to an on the surface glance. 2. enable it with examples. Include CloudFormation or Terraform scripts to set up each piece so that we actually build something. Documentation is important, but you can't learn without doing. 3. test against the security you've put in place.
So basically a forum? Knowledge Management is a broad topic and it's hilarious seeing the same solutions brought up again and again.
I have all this persistent information! New people need to get up to speed fast - where do I put it? Cue the Wiki fad.
I have to get things done and elicit quick feedback ASAP! Cue the Chat fad.
I want async communication so I'm not bogged down all the time! Email and Forums.
There's a time and place for all of these.
I would prefer the image to look identical. Each host is going to have a unique name, and you're going to outsource your routing/discovery to the Client/another service anyway right?
Generally though, if there is some custom config data that must be passed on BOOTSTRAPPING the node, you can use templated values for user-data on cloud-init based systems, or the remote_exec provisioner. This can even include the modified shard name (with count). If you're talking about updates AFTER the machine has been in service, I do not believe this is 'officially' supported by Terraform but it can be done [0]. You may want to look into a proper CM tool w/ idempotency for that sort of thing (Chef, Salt, etc.)
0: http://stackoverflow.com/questions/37865979/terraform-how-to...
Some basic conditional logic was added in 0.8 [0]. The reliance on 'interesting' declarative tricks, e.g. counts for conditionals and loops, is a little annoying I agree. However, it looks like they're listening to the community and will build on these features in the future. There's a lot to work on :)
0: https://www.hashicorp.com/blog/terraform-0-8/#conditional
Great changes! State environments is the feature that stands out the most for me. Currently, this is done by managing different sets of TF VARs. That's not going away, but this should allow for more nuanced modules.
Someone has been reading Rothfuss.
I type roughly 150 WPM without many errors, though I can burst much higher. The last disconnected keyboards I tried were:
* Apple Wireless Keyboard
* Logitech K 300
* Microsoft -god-knows-what-it-was-called- from back in the day.
In all cases, I experienced stuttering or dropouts of my input at high speeds. This did not happen all the time, but it was frequent enough where I felt the need to go back to a wired keyboard (currently Filco Majestouch). Maybe I had a bad batch, or something was interfering with the signals in my homes. Either way, I don't plan on recommending wireless alternatives for quite some time.
Do you know anyone that purchased Logitech keyboards for those sweet visuals on the tiny LCD screen? Me neither. This is a total gimmick. Power users don't look at the keyboard, it's a waste of time.
Not a knock here since I know this is not a majority case, but for marginally quick typists, I would say these wireless/bt keyboards are useless. Input lag is dreadful.
Right, if I want to rely on Finagle's RPC capabilities, e.g. load balancing, routing, tracing, etc, then my microservice must be JVM based and use the Finagle library. This is a standalone proxy deployed as a 'sidecar' app alongside my service. This allows me to implement the microservice in any language I want and get some of the features listed previously.
Of course you now have another moving part in your system :)
I believe part of what the author is looking for is currently being pushed by the Deis guys with Helm[1]. Think of it as a package manager for creating Kubernetes configurations. I think we'll see some stable and reusable templates for both stateful and stateless services there.
[1] https://helm.sh/
I use an older Pi with Raspbmc (osmc) and I can stream 1080P movies just fine. The key is to 1.) Avoid streaming off a slow disk e.g. NAS, 2.) Ensure you have the necessary bandwidth to stream (no slow wifi), and 3.) Pass DTS audio to your receiver for decoding so your PI isn't doing double duty for audio/video.
Keep your diet in check and eat your TDEE or less in calories to maintain weight or lose a few pounds. That's 90% of it. Sign up for a gym and workout 3 times a week aiming to improve strength if you want some muscle definition. That's the other 10% if you want to get fit.
Do you think you could write a blog post about this? Finding interesting uses for Roslyn may help drive its use in the community. Plus, that just sounds interesting.
I don't believe this is true at all. Dependency injection is just a way to invert control, decouple your code, and make it more testable. Proper tests of your configuration when your container is bootstrapped is all that is necessary to maintain sanity here.
You are still getting all the benefits of static typing, especially if you are coding to a contract.
To those who are confused by the name, this is not a Jabber / XMPP service. JabbR started as an example chat app for using SignalR[1], an open-source, realtime signaling library for .NET written by David Fowler & Damian Edwards. Think of SignalR as Socket.IO but for the .NET world (and Mono compatible).
This has grown into a more mature self-hostable chat. I just threw a version up on AppHarbor 10 seconds ago and I have to admit I'm surprised by the amount of features this thing comes with.
Side note - If you're curious about how scalable this is, SignalR is built on .NET's IAsyncHttpHandlers & TPL (async made easy). I suggest you take a look at the source code.
I'm seeing a lot of surprise by the lack of NFC, but given the lack of market adoption, I can understand why they may not take it as a high priority. Plus, we've all seen the reports of Apple purchasing AuthenTec and its IdAM solutions. Fingerprint + Passbook + NFC and they will have all the pieces in place to create the NFC market with aggressive merchant partnerships.
Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?
Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.
I don't agree that this is entirely nitpicking. Sure, ripping apart some code in a controller might be considered coming down hard on a brand new project, but a lot of his criticism is directed towards the foundation/model behind the system as opposed to "You missed a semi there." Hell, he even mentioned ways they could integrate existing services (G+) into this project.
Oh well, at least they shipped.
Adding a quick note here about Ramadan - the act of fasting and feeling hungry, thirsty, and tired also serves to invoke feelings of empathy with those who are less fortunate. Essentially, it is a reminder that there are always those who are in need. This is why muslims are encouraged to donate to the needy during this month.
Simply sleeping through the fast and reversing a sleep schedule seems to go against the spirit of the exercise. Of course, everyone fasts for different reasons and it is a very personal undertaking. I just wanted to clarify for those who may be thinking "Why bother doing it at all if you can flip your sleep schedule?"
CDC is definitely a more enterprise-y feature (Oracle, SQL Server, etc.). I have had to build the same sort of tracking via triggers in the past, so I would definitely agree with you. I am not super familiar with the PostgreSQL road map, but maybe it is a long-term goal.
This sort of event buffer may also be achieved by leveraging Change Data Capture (CDC) features if they are supported by your data store. For example, when CDC is enabled in SQL Server, an agent service will periodically examine the transaction log and move data changes to transient "buffer tables" automatically. Since this is happening as a background service, there is no need for a developer to explicitly perform a write operation to these buffer tables.
I agree the message is the most important part of this despite the immature way he exposed this GitHub security issue.
Rails can certainly adopt an 'opinion' regarding this issue, but if I think if we were to take a look around at heavy web frameworks today, we would see a very similar approach of "let the developer decide" when dealing with Model security and serialization of fields.
These framework devs have no idea how people are going to use their models, so forcing them to whitelist everything by default may cause unnecessary headaches. Instead, they provide tools to prevent this exploit from happening should devs expose the model.
I would not necessarily expect my client application to invoke these functions automatically. It can be very helpful writing client apps when there is a human making these decisions.
One of the primary benefits of HATEOAS is state management of your resources becomes easier. My client does not need to burden itself with interrogating the state of the resource, knowing available business functions and when they should be invoked, knowing the location of these business functions, etc. This is managed on the server via API and the client can stick to "following the links."
e.g. "Create Blog Post" is a REL that I have discovered at application root. After invoking this function and creating the post, I receive a 201 with a post resource that looks like below:
PostResource, SomeData, Link -> "/Modify Blog Post", Link -> "/Delete Blog Post", etc.
In the above example, my client application can display the links it is given and as a user I will modify or delete the post by simply selecting these functions. The client app is acting as a state machine for my user, and they are given the option to transition to various states based on the links returned with each response from the API.
There are many other benefits to HATEOAS, of course, one of which is it allows your application/api to grow and change over time (maybe I want to change a non-core URI down the road?)...this can be done without a lot of pain points by leveraging HATEOAS.
TLDR: HATEOAS constrained APIs are meant to provide direction (in the form of links) to consumers. This can lead to lightweight client agents that do not need to worry about application state.