pscarey

It's easy to make a (poor) copy of the product. It's hard to execute the idea, take market share, and capture customer revenue.

Asana blogged this year about 50k organisations, 6 quarters accelerating growth [1].

Back in 2015 they blogged mentioning the heating up 'enterprise collaboration market'. There's countless office tools, diagramming tools, collaboration tools. Even in software there's more CI systems than I can count.

My guess is there's a big market which the VCs think is accessible to Asana in a way it's fundamentally not to a competitor. Combined with big growth it makes sense.

[1] https://blog.asana.com/2018/09/asana-company-updates-2018/

It'll be interesting to see where TS goes over the next couple of years. They seen to have a short roadmap.

The proposed @types scaffolding seems interesting for solving issues with untyped libraries. Maybe the focus will be how do we actually get all the code typed rather than resorting to 'any'.

Side note, quite amusing: https://twitter.com/kitsonk/status/973651805950242816

Go along to a wine tasting if you want to see the difference. It's much easier to notice and appreciate flavours side by side than with different meals. I'm not a massive wine drinker, but I really enjoyed several tastings in NZ, and could clearly tell the difference between the wines.

I have a workable setup with Gitlab CI - my g1-small runner starts a preemptible vm on GCE with docker+machine, and using node: alpine & coreos its about 5-10s before its ready and running the ci job.

Why so much security focus on a non-internet connected PC, but so little focus on needing a non-internet connected (ever) printer?

The printer is potentially an easier attack vector, and you've got to pass the funds into an electronic wallet prior to spending, presumably on your PC or phone, whilst an internet connection is enabled.

Seems writing the wallet info down with a pen, then doing your best to ensure security when you have to use the wallet (e.g. live CD) is a better method?

It's not gobblygook, it's training at a serious level. Those levels correspond well with lactic acid levels in the blood, for various types of training. I've both rowed at a high level and done tech research work with an Olympic cycling team, and this (or variants) are used frequently. HR for power (not pace etc) is a good measure of personal fitness and wellbeing (e.g. high resting heart rate means you're possibly falling ill or not well rested). However, all this doesn't matter for anyone who just wants to be healthy. That said, I defer to Garmin For proper HR smart watches and accessories, which are tailored for specific sports.

You can do everything you want with Firebase Remote Config, for free. Can even randomly pick out a % of any analytics audience you create.

BaseUp | Android + iOS, Frontend or Full Stack Developers | Sydney, NSW, Australia | ONSITE, INTERNS | https://www.baseup.com.au

BaseUp has created a parking management platform for CBD buildings, which combines a web portal, mobile apps and hardware to provide seamless management and access control. Our platform automates management tasks, generates cost recovery and provides employee benefits.

The right candidate will be interested in:

  - Providing great user experiences.
  - Ensuring the security of our platform.
  - Effective applications of IoT to produce business value.
  - New ideas for offerings to our customers.

Technologies:

  Mobile: Android (Java/Kotlin), iOS (Swift)
  Backend: Node.js, Typescript, GraphQL
  Frontend: React.js, Redux

Surely the (already) observable relative difference is more important than what the car thinks it's speed is? Both cars might read 60mph and go at different speeds. Therefore I don't see much need for that to change.

I think more interesting would be smarter traffic control systems which communicate with cars in cities to advise traffic flows - a simple example being a (wirelessly) counting down light rather than red/amber/green.

The website is unusable on mobile - too much animation pretty much killed Chrome and scrolling resulted in very gradual stuttering down through the pages segments.

I believe that most arguing over the internet doesnt qualify as debate, and consider it somewhat of a lost skill. Critical thinking/analysis is not undertaken by most people, particularly on the internet.

Debate is a cornerstone of democracy - to take the climate change example, anyone should be able to question it, and the evidence for it should be what persuades the majority of people, leading to a decision. In these cases, debate is a very effective mechanism. Unfortunately, people don't tend to engage and debate properly.

A good, reasonably relevant read (5 min) is Isaac Asimov's A Cult Of Ignorance, which I think goes some way to explaining the lack of engagement with debating.

I think you seriously underestimate the threat of a real fire - a mistake which a lot of people (rather sadly) make. People die in house fires because the do not wake up in time to get out - the place goes up pretty quickly, and smoke (+ poisonous gases) incapacitate and suffocate people before they even have a chance.

Many resources in this area, but as a starting point: https://www.ready.gov/home-fires

It seems you've found the source of the obesity crisis!

Even better in Australia - A$100 limit on 'PayWave'/Contactless transactions. All you have to do is tap your card and wait a few seconds.

UK has contactless, but lower limit and from my recent visit, seems to not be as common.

Thanks for sharing that link. I found it quite an interesting read. (I much prefer Swift to ObjC after a conversion of about 10k lines in an iOS app).

C style for loops come pretty early in most programming tutorials, but I wonder how much non-C programming does actually use them nowadays (from the Community Responses, it seems not much Swift courtesy of other options). Usually, a C style for would be to loop over an array, and a safer way to do that probably could have stopped countless vulnerabilities & bugs occurring over the years.

"spanning 10,000+ VMs handling 100+ microservices" ?

I'm currently using Firebase at work (startup, mobile app, web dashboards), and I think it's got some great features.

It's not a replacement for SQL, but an entirely different product (and has no doubt come a long way since V1, especially with Firebase Functions out recently). You have to make tradeoffs, like data duplication, for the advantages. From the sound of it, the advantages probably aren't relevant to you, but I'm confident they exist for us.

- We only have to store a comparatively small amount of user data for the lifetime value of each user, so the actual database cost is marginal (i.e. data duplication is not expensive to us, as long as reads are fast). (Development) time is (very) expensive.

- Rapid development and iteration. I can make additions and make fields redundant with ease in response to customer feedback, my own development choices, and changing product needs. There's no API update needed, as reads are client side. I have data model classes which store the reference in the database, some constructors, and getters and setters (About the same as any other data model + API would have). The release goes live and data just starts being manipulated in a new way. Alterations can have simple defaults with || in JS and ?? in Swift (even if it's just an empty string).

- Minimal backend. Our application doesn't require much backend logic, and that which we do have is mostly event driven with Firebase Functions, upon certain database writes. Works out quite cheap too (for now - most usages don't trigger any functions).

- Caching, and offline first. We take the approach that it doesn't matter if there's a short delay in 95% of our data updating - either due to patchy mobile signal or the data taking time to sync down. Firebase has made on device caching and real time updates to that data a breeze. With GeoFire, we've got instant map search (keys are cached by Firebase and contain sufficient information to filter, etc).

- Declarative security rules are very powerful, and can even reference values in the database itself for security control - effectively. We store a permissions tree in the database for our more complex security logic.

As a bonus, additional features like Authentication, Analytics, Push Notifications, etc are all convenient to have bundled up.

As you can see, most of this isn't about the database tech, but the development speed for us. The perceived costs and inefficiencies may exist in the database itself, but there are massive advantages for the application development as a whole.

With hot code pushing, you're deploying newly written code/functionality, post release (opening possibility of up MiTM attacks etc).

With Remote Config you deploy the code, then decide what to show to users post release. This gives Apple a chance to review all the code submitted to the App Store.

In the case of rolling out features an A/B tests, you'd make a release including a feature, but only enable it x% of your users using RC. You can then obviously enable it for everyone if it passes your A/B test or if you're happy its working.

AFAIK Remote Config is just a server side key value store with customisable values based on audiences (e.g. random 50% for A/B testing, all people from Country X). This means all behaviour changes will require code to be deployed in the first place.

Also, from Firebase Docs[1] "Don't attempt to circumvent the requirements of your app's target platform using Remote Config."

[1] https://firebase.google.com/docs/remote-config/