bobf

Wanting to see how "a feature that we needed" works is better phrased as a "solution". It solves a problem you have. The quote your referenced is simply saying that a large feature set is not the most important thing; whether it solves your problem or not is the key.

I tried Glass but returned it after a few weeks. It failed for me because it didn't provide enough value for the hassle it added. The main pain points for me were that it wasn't particularly comfortable, had poor battery life, didn't offer enough useful features (at the time at least), and that a large amount of people I met in a day wanted thought they should ask about it, want to try it, etc.

The same idea applies for other fruits and vegetables, like corn, peas, and especially peaches and pears. The trick is finding a good canned variety. Most mass produced versions from the familiar large names (Dole, Del Monte, etc. in the US) are not great. However, for example there is a smaller grocery chain near me which brands their own delicious version of canned peaches from a regional producer annually at the peak of ripeness.

In my view, the problem is actually that theaters often do not have equivalent quality for 3D and non-3D. The biggest, best screen may show 3D IMAX all day long, because that's what is most profitable. Seeing movies in 2D on the highest quality screen/projection/sound has been fairly difficult in the last year or more.

Hawaii isn't considered international, from the perspective of the US - it's domestic. Notice that there also is not a trip to Alaska shown, though he did visit Alaska. (And, trips in the mainland US are not shown either.)

It's great to see a solution that works using some basic hardware and existing blinds. Not only does that make it incredibly cheap compared to commercial alternatives, but it also doesn't require implementation at time of construction (or a major renovation).

I recently have been working on the technical aspects of building a new house for my aging parents. We went with Lutron's Serena shades, because we also used Lutron's light controls and they feature both Nest and Alexa integration. Construction hasn't been completed yet, so I can't fully report on the final result. But, my initial tests have gone well and setup was simple. For reference, the per-shade cost is around $600 installed. Basic shades of similar quality would likely be $150-200 each, so it's a fair bit more but not outrageous.

I considered a DIY approach, but then thought about the primary users and realized an off-the-shelf solution would be best. Even in your own home, it's hard to overstate the importance of reliability and ease of use for your spouse, kids, guests, etc.

Tokyo is consistently ranked as one of the best cities to travel to or live in, in the world. I visited Tokyo recently, and found it to be exceptional in many ways. Aside from Patrick, I've never heard of Ogaki and I suspect most people wouldn't have either. Imagine the best of New York, San Francisco, etc. combined in an even larger city that is extremely clean, polite, hard working, and efficient.

Moving to your own hardware will almost certainly improve performance, reduce incidental downtime, and cut costs substantially. Including hiring more engineers, you might expect total costs to be ~40-50% of what you would have spent on cloud-based services over the first 24 months. If your hardware lifecycle is 36-48 months, you will see large savings beyond 24 months.

A few things to watch out for, if your team doesn't have a lot of experience in direct management of dedicated servers/datacenters:

- There is an increased risk of larger/longer very rare outages due to crazy circumstances. Make sure you have a plan to deal with that. (I've had servers hosted at a datacenter that flooded in Hurricane Sandy, and another where an electrical explosion caused a >3 day outage..)

- It's easy to think you'll rely on managed services, but that rarely works out well. It also can become very, very expensive -- possibly more so than cloud-based hosting.

- Specifically, regarding H1, H2: Dedicated hardware is substantially cheaper than cloud-based hosting, but if you rely too much on managed services you negate a large portion of the savings. Consider that most service providers will be both more expensive and less competent than doing it yourselves. Also, having your own team have direct knowledge + their own documentation of the setup will be beneficial.

- I'd recommend budgeting for and ordering some extra parts to keep on hand for replacement, if you are having datacenter ops handle hardware or can have an engineer located relatively close to your datacenters. (A few power supplies, some memory, a couple drives - nothing too crazy.)

- Supermicro's twins systems are great. In the past I've gone with their 1U models vs. 2U to slightly reduce the impact of unit downtime. (Having to take one 2U Twin down affects four nodes. It sounds like you'll have to decide on balancing that against the increased drive capacity, in your case.)

The sheer size is almost unimaginable from the perspective of an individual walking around, if the 4 million sq m listed in the article is accurate. For comparison, that means Yiwu is roughly 400x larger than an average Walmart -- and certainly must be much more densely stocked.

I recently visited Seoul's Dongdaemun shopping area and the scale was shocking. It includes dozens of massive, multi-story buildings that span roughly 10 city blocks. When it was built in 1970, it was the largest such market space in Asia. (They claim it is still the largest, but perhaps the distinction is because Yiwu is considered a city.)

If the average city block is ~10k sq m, then 10 blocks with an average of 4 stories per building yields 400k square meters of space.. which is a mere 10% of Yiwu's claimed size -- wow! You could spend weeks walking around Dongdaemun without seeing everything, but the experience was similar to what the article describes Yiwu as -- booth after booth of the same types of mostly wholesale merchandise.

Definitely! My own favorites are the tonkotsu ramen broth and chocolate chip cookies. (And yes, there are massive, in-depth posts about making the noodles and the cha siu pork belly to accompany the ramen too).

http://www.seriouseats.com/2012/02/how-to-make-tonkotsu-rame...

http://www.seriouseats.com/recipes/2013/12/the-food-lab-best...

Some aspects of zero downtime DB migrations require your changes and deployment protocols to follow certain rules, so I'm not sure a generic automated solution is possible. I was writing and speaking a fair amount about this back in 2012 and the concepts are still basically the same today -- I'll outline the core ideas here and provide a few links with more configuration examples, etc. at the end.

The basic idea behind zero downtime DB migrations is to use a Blue-Green deployment model. Blue-Green deployment uses two identical production environments, called "Blue" and "Green", with a router or proxy setup in front of them. Only one of the environments serves traffic, while the other is idle.

For our example, let's say Blue is initially live. When you deploy new application code, it would be deployed to Green and tested. Once you're happy with it, you switch the router or proxy to send requests to Green. Blue becomes idle, and then you update Blue.

With MySQL as the database, I like to call this setup "Active-Passive", using a Master-Master infrastructure. Normally, Master-Master implies an "Active-Active" setup with each instance being able accept reads and writes. (People that have used Active-Active Master-Master MySQL recognize the big downside: conflicting writes break replication.)

Using an Active-Passive approach for supporting zero downtime schema changes lets you avoid the problem of conflicting writes break replication. Basically, think of Active-Passive as the ideas used in Blue-Green deployment, extended to your database.

The basic process is:

  - Run STOP SLAVE on both the Active and Passive servers.
  - Run SQL for the schema change on the Passive server.
  - Run START SLAVE on the Active server.
  - Wait for replication lag on the Active server to become small enough (ideally about a second). You can check replication lag with SHOW SLAVE STATUS "Seconds_Behind_Master", although that isn't 100% reliable and you are better off with something like Percona's MySQL Toolkit's pt-heartbeat.
  - Run LOCK TABLES on the Active server for the final replication catchup
  - Ensure replication lag is zero on the Active server
  - Modify your proxy configuration to change the Active/Passive designations
  - Unlock the new Passive server
  - Run START Slave on the new Active server

Now, there are some limitations:

  The new schema must be backwards compatible with the previous schema:
    - Add new columns with triggers rather than modifying in place.
    - New columns cannot be required immediately, or old writes will not replicate appropriately.
    - You can't use server-generated data functions (UUID, NOW, RAND, etc)
  And it can't conflict with pending writes:
    - No auto-increment INSERT unless the application doesn't insert to that table.
    - No DROP COLUMN nor DELETE rows if they are used in the previous schema version.

Resources:

My article in SysAdvent on Zero Downtime MySQL schema changes: http://sysadvent.blogspot.com/2012/12/day-3-zero-downtime-my...

Slides from a presentation I gave at a Devops conference in 2012: http://www.completefusion.com/zero-downtime-deployments-with...

Pivotal Labs about Blue-Green deployment: https://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-...

(As a side note, if you haven't heard of it before, SysAdvent is awesome: ~25 sysadmin/devops posts published annually in December.)

Parma is an incredible town for food, and the whole Emilia-Romagna region is worth an extended visit. I spent 2 weeks exploring the area last summer and loved it.

Within a 30 mile radius of Parma, you can sample some of the best fruits and vegetables, stuffed pastas (ravioli), Parmesan cheese, balsamic vinegar, wine, and sausages in the world -- almost unbelievably cheaply! If you're looking for pesto di cavallo in particular, there's a great sandwich shop in Parma called Pepèn that I'd suggest.

The cheaper kamado-style/big green egg clones are pretty good these days. I recently picked up a Kamado Kooker with stand for ~$300 vs. >$1000 for the similar size Big Green Egg and stand, and have been quite happy with it.

I'm pretty unhappy with them, but for different reasons. I ordered more than a year after their Kickstarter -- as a pre-order through their Shopify site. At that point, they had indicated they were going to ship units "soon", so I felt the pre-order would be fulfilled in a timely manner.

I had intentionally avoided backing the Kickstarter because I didn't find the risk to be worth it at the time.

One thing I learned through the process, which everyone should be aware of: there is no consumer protection available with either Shopify or American Express Platinum (famous for it's high level of customer service, "return protection", extended warranty on purchases, etc) if more than 60-120 days passes after a purchase and you haven't received the item.

Lesson: file claims early.

Don't order pre-order goods with uncertain delivery dates (or if you do, don't let them slip past 60 days from the order date without filing a claim for a refund with the merchant provider or your credit card company).

I hope you'll be able to upgrade the module and retain the same case+band, but I haven't seen anything definitive from Apple to say that's likely.

They sent out a different email to Explorers that returned Glass (I did) --

Hi there,

It’s been an exciting ride. We learned A LOT and now we’re hard at work building the future of Glass. You gave Glass a chance-even if it wasn’t right for you right now, you were still part of the story. That means a lot to us, so we wanted to share this collection of photos and stories from the early days of Glass.

Download Vol 001

Shots from the Glass yearbook

You’ll start to see new versions of Glass when they’re ready, and they’re built on what we heard from Explorers like you. We’ll be eager to hear what you think.

Best wishes, The Glass Team

You're not going to get rich from this. AWS limits you to ten spot instances of this type, and profits per ten instances per day are probably going to be $20-30. I've been mining with this setup for ~4 hours and have amassed ~0.2 coins ($8!).

It isn't available in all regions. What region are you looking at?

It could, but we're talking about a specific GPU instance in this case. I wouldn't see an obvious correlation between Black Friday and the g2.2xlarge instance type.

Indeed. I would estimate that at current LiteCoin values and difficulty level, mining on EC2 will stay profitable until the spot price for these instances passes $0.20-0.21. One thing that will slightly slow down the abuse of this is that by default AWS limits you to 10 spot instances per region for the g2.2xlarge type.

I'm the author of the post. I didn't include a lot of background detail because I wanted to publish the technically interesting bits quickly. As I see it, mining LiteCoins on EC2 is currently profitable because of four main factors:

1) Bitcoin's recent dramatic increase in value. (LiteCoin's value is heavily correlated to Bitcoin's.)

2) The relatively low difficulty level for LiteCoin mining right now.

3) Spot instance pricing for the EC2 GPU (g2.2xlarge) instances.

4) LiteCoin can be mined using both GPUs and CPUs (although GPUs are dramatically better, another ~35 khashes/sec from the CPUs is still nice).

Interestingly, the previous average historical spot price for these instances was ~$0.075/hour. The spot pricing has now jumped to $0.10-$0.12, depending on region.

As an added bonus, you may be able to get $100 of AWS credit at http://aws.amazon.com/big-data/powerof60/ which would give you 2-3 free days of mining.

I had a similar experience around the same age and year, except it was with FreeBSD. I got it to boot once, then tried to change the bootloader setup to allow dual booting with the existing MS-DOS 5.x installation. You can imagine how well that went, as a 10 or 11 year old with no previous FreeBSD/Linux experience. My parents were not quite so understanding about why I had broken their $3000+ computer and lost all their files. It took a few days, but I eventually managed to fix the MBR by reinstalling MS-DOS. Imagine my surprise when I booted into MS-DOS and found out that the files were still there!

5+, with another 5+ I don't carry but will use once in a blue moon. These include both business and personal cards, with branded versions of various cards.

Securing your instances in what way? Elastic Beanstalk should initially provide you with instances that one would expect to be reasonably secure, but I wouldn't rely on that level of presumed security for anything important. It definitely does not provide a fully managed environment on an ongoing basis. One glaring example is that it does not handle things like OS-level security updates/patches, or provide you with instances running updated AMIs unless you re-setup your EB environment.

Great suggestions, thanks! I'm sure a whole book could be written about HIPAA compliance and AWS, but a lot of general AWS security best practices will end up being useful towards a goal of HIPAA compliance. I'll definitely be covering encryption at rest, VPC, and multi-region deployments. CloudFormation DSL also seems like it could be a separate book (or even a series of books, like you see with Puppet/Chef), but I'll try to include what I can when it is relevant to architectural decisions.

Sure! Can you expand on what you're interested in specifically, if anything? (Or is it just top to bottom/ basics to advanced OpsWorks that you're looking for?)

Definitely! Fault tolerance is one of the biggest goals people have with moving to "The Cloud", but one of the least well-understood AWS topics when it really comes down to the implementation details.

Any feedback on topics will be awesome. Also, there's a free 30 day course on AWS best practices at the book launch site (http://awsarchitecture.com) if you're interested.

I lived in Vegas for a few years, and never ran out of interesting things to do. There are lots of great outdoor activities like mountain biking, hiking, golf, etc. that you can enjoy at least 10 months out of the year (depending on your tolerance for heat in the summer). You can even ski at Lee Canyon.

Although you're dismissive of the strip, and I can understand why from the typical visitors' perspective, there are literally tons of things to do there and many of them are significantly discounted or free to Las Vegas residents. I did the math and over the course of 3 years I went to tens of thousands of dollars of things for free.

There are concerts, some of the best restaurants in the world, conventions, boxing, shopping, and more. Traffic is manageable. Cost of living is low. Flights to most places are cheap. You can be in Southern California or doing outdoorsy stuff in Utah for the weekend with a few hours drive, or easy 1 hour flights.

Setting up a standard naming convention for hostnames is more logical, efficient, and scalable. Include useful information in the hostname, so you don't have to map random lists of names to functions. "What does server 'Foo' do again? Oh, it is a database server. Was that production, dev, or test?" Do you (or one of your operations team) want to be figuring that out at 2AM when you get an alert? Depending on your setup, something like this may be appropriate: <location>-<notation of physical/virtual>-<function>-<#> (e.g. bos-xen-mysql-005, being a virtualized Xen-based MySQL server in Boston). If you have multiple environments (dev/test/prod), add that too.