vyshane

Fountain pens are like mechanical keyboards. People use them because they make the act of writing _feel_ good. It's not about the tech, but rather about the pleasure of using the instrument. How smooth do you want the nib to be? How much feedback? How bouncy/flexible? How much line variation? Discovering (or modding) your preferred nib is a bit like discovering the one switch that suits you really. A bit of a rabbit hole... And then of course you get into inks.

No backpressure in RxJS.

That's a tough one to automate. Right now, it involves logging a manual time entry to your timeline (then posting it). If you walk away from your computer and come back, WiseTime will ask whether you want to log the time (or part of it).

If you wake up in the morning, jump into the shower, solve a problem there, and hop onto your computer, WiseTime will then offer to log the last several hours including your sleep time. Edit down to 10 minutes (or however long your shower was) and log it. A bit contrived, but that's the best I got at this time. It's a tough problem to solve ;)

This article resonates with me. I feel very strongly about spyware (Bossware is too kind). Views expressed here are my own, not those of my employer.

I work for a company that makes an automated time tracking product (WiseTime [1]). We migrated our infrastructure to EU/Germany because we wanted to fall under a jurisdiction that is one of the strictest when it comes to privacy. This is how we think about the problem.

- Many professionals (lawyers, contractors, ...) get paid for the time that they bill their clients

- Manual time tracking (start/stop stopwatch) sucks

- Automated time tracking is an order of magnitude more convenient

- If you are going to automate the problem away, make sure that the system cannot be abused to spy on people

- Otherwise no one will want to use it!

We view privacy as one of our most important features, and our systems were designed from the ground up to protect it.

- Your activity is captured into a private timeline that only you can see

- To make your time available to your team, you must select the activities that you want to share, and explicitly post them to the team. It's like sending an email. Your draft is private, but once you send it off, then your recipient has a copy of it.

- We allow you to anonymise your posted activity data when you leave a team

- We allow you to specify filters around what activities should and shouldn't be captured. Of course you can delete anything you want off of your private timeline.

- We provide user-level and team-level data retention settings. We automatically purge data that falls outside of your desired retention period.

- We silo our data layer so that we don't store any personal information with user activity data. User activity data is siloed away from posted team data, and so on.

- We take GDPR seriously and we even have automated processes to purge data from our Sales team's CRM

We are a remote-first team, and we wanted to build a system that we personally dogfood without any qualms.

[1] https://wisetime.com

3 years ago, I also wanted a bare metal cluster for my homelab. I wanted x86-64, low power consumption, small footprint, and low cost. I ended up building this 5 node nano ITX tower:

https://vyshane.com/2016/12/19/5-node-nano-itx-kubernetes-to...

I think that the exposed boards adds to its charm. Doesn't help with dust though.

This post on the Swift forums gives a good overview of Swift gRPC: https://forums.swift.org/t/discussion-grpc-swift/29584

The NIO version of Swift gRPC is currently at v1.0.0-alpha.6. Hopefully we'll see a 1.0 version soon.

Swift gRPC repo: https://github.com/grpc/grpc-swift

How about the equivalent of RxJava instead: https://developer.apple.com/documentation/combine

Unfortunately not available on Linux, so server side is out :(

TL;DR

I was pretty excited when Apple announced SwiftUI and Combine at dub dub this year. I have been following the Swift gRPC project, and when they released their first 1.0.0-alpha version not long after, I decided that the world was ready for CombineGRPC, a library that integrates Swift gRPC and the Combine framework.

I dreamt of beautiful, responsive UIs; of streaming data straight to my lists as the user scrolled. Then I woke up and got hacking.

FoundationDB Record Layer uses protocol buffers out of the box. They leverage the fact that you can evolve protobuf messages in a sane way. That's their equivalent of doing database schema migrations.

Both. And if your external clients rather consume a JSON/REST API, it's easy to derive that from a gRPC API. You can do it right there in your protobuf definition. It's actually easier to do it that way than to deal with OpenAPI's wall of yaml.

gRPC has been solid for us on the JVM, and streaming has been great when consuming from Apache Flink jobs, integrating with message queues, receiving push notifications and so on. For async work it's useful to have more than just request/response.

I've been playing the FoundationDB Record Layer for a personal project of mine, and with this setup I can generate not only the API implementation, but also the models used by the persistence layer:

Protobuf (Messages) -> gRPC -> Scala/Monix -> Protobuf (Models) -> FoundationDB

We've been using gRPC and Protocol Buffers for the last couple of years. We write APIs using the Protobuf interface definition language, then generate client libraries and server side interfaces. Then it's a matter of implementing the server by filling in the blanks.

I had good success with the CoreOS Kubernetes Vagrant boxes [1]. However, I switched once Kubernetes became usable via Docker because the latter gives me super fast setups and teardowns, allowing me to iterate quickly on infrastructure code.

[1] https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagr...

GKE is why I am personally switching from AWS to GCP. I'm running Kubernetes on AWS at my current gig, but I'd rather not have to build and maintain the cluster myself if I don't have to.

Forget about RoR clones. I want Swift/OTP or Akka.Swift!

Hi Solomon, do you have an ETA for Docker 1.7? I see that it's currently in RC1. How soon will we be able to take advantage of libnetwork via Compose? Is there any documentation yet on how it will be done in Compose? Is there currently an easy way to try it via Boot2Docker?

Sorry about the barrage of questions. As you can probably guess, I'm very interested in trying this out.

SEEKING WORK, Western Australia or Remote

Interested in:

- iOS development using Swift and Objective-C

- Android development using Java, RxJava

GitHub: https://github.com/vyshane

LinkedIn: https://www.linkedin.com/profile/view?id=10555387

Why assume that they are using Docker because they have a portability problem?

They probably like OS X as a workstation OS, and want to use Docker for the DevOps benefits that they gain from it. boot2docker is just a lightweight solution for running Docker locally.

Congratulations on the new release!

I can already see that `docker exec` and `docker create` will allow me to get rid of a number of admin and configurator containers.

When I started playing around with boot2docker, I was gagging for the ability to share directories with OS X. However, it turns out that I didn't really need that once I realised that caching means that building images is very fast.

Recently read:

Programming Elixir - Dave Thomas

Introducing Elixir - Simon St. Laurent and J. David Eisenberg

The Swift Programming Language - Apple

Currently reading:

Functional Programming in Swift - Chris Eidhof, Florian Kugler, and Wouter Swierstra

Recently purchased but not started:

The Algorithm Design Manual - Steven S Skiena

Sipping from time to time:

Inverting The Pyramid: The History of Football Tactics - Jonathan Wilson

For me, it comes down to the fact that I find Auto Layout more declarative. I'm `saying what I mean` when I apply constraints - that can be done in code too, of course, although Xcode 6 is getting pretty good at surfacing that information. Whereas when I'm dealing with a box model I'm having to play compiler in my head. LinearLayout, RelativeLayout - these are terms that are optimised for the computer to understand. Constraints are the way we humans think about things. "Element A should always be 10 points to the left of Element B".

It's a bit like imperative vs. functional programming. In the former model, I have an idea in my head and I need to nest containers step by step to get to the final form. In the latter I'm simply building up a ruleset.

But like I said, that was my personal preference. I guess we'll have to differ on opinions ;)

iOS has always been able to do fluid layouts. It was possible with Springs and Struts (though a PITA), and from iOS 6 onwards has Auto Layout, which I personally find better (more declarative) than Android's box model.

iOS uses logical points, i.e. a DIP on Android.

As for iOS's @1x vs. @2x images, think of them as your drawable-*dpi resources on Android.

The Scala folks like to say that newcomers can start with procedural OO and then slowly grow into the functional mindset. Developers don't need to learn and use all the language features from the get go. I suppose that the same advice applies to Swift.

Having said that, Swift is not nearly as intimidating as Scala.

I've read this post. I would still recommend that you jump straight into Swift. Objective-C has its own set of quirks and pain points. If I was starting over, I would go straight to Swift. It's an altogether nicer and more consistent language.

Well, to be fair, Apple have other books that cover Cocoa and Cocoa Touch. A book about Swift is... about Swift.

Have you looked at the code? This is not reinventing the components. This is basically UIKit with a few things added to it.