HN user

mweatherill

76 karma
Posts2
Comments27
View on HN

When my daughter was 5 she told me off for driving too fast to school. She was annoyed that whenever I drove fast she would be late for school.

Have you seen Azure Data Studio? It uses the same code base as Visual Studio Code and has first class support for notebooks. It includes a PowerShell kernel

Whilst jupyter notebooks are often synonymous with python code, the languages are actually pluggable by using a different kernel. Microsoft have implemented an SQL kernel which means you can write SQL queries directly in a notebook.

Microsoft have released another IDE with notebook support called Azure Data Studio. It uses the same underlying code base as VS Code but is targeted at data driven tasks such as connecting to databases.

Strangely, it uses a different jupyter notebook implementation to VS Code. I found it avoids some of the annoying bugs mentioned in another comment.

It also introduces a SQL kernel which I’ve found useful for organising my queries.

It is very unlikely that the process control network is connected to the Internet. However it is almost certainly connected to the corporate Intranet. Think about all of the metric data available on the process control network - that is needed by engineers for analysis, ERP systems for financials, asset management systems for maintenance etc. With an air gap, you can't do any of that in real-time.

Windows has overwhelming market share in the process control industry. Microsoft has long standing partnerships with the majority of the process control vendors. The attach surface argument was never relevant when networks were physically isolated. There is a slow shift towards Linux however many systems have extremely long lifespans.

Selling to enterprise developers is a grass roots strategy into the enterprise. Applications and services use a freemium model to get their initial users with the hope of becoming business critical. Once the tools show their worth, they are deployed at scale which triggers the paid version.

This approach has worked really well in the DevOps space since there is a strong motivation to use the same tools in development and production. Rather than being dictated from above about what tools to use, the developers are going to their management and saying "we need this to do our job". The enterprise ends up paying to keep their developers happy and productive.

The fundamental problem with social media sentiment analysis is that it is based upon the assumption that tweets are representative of the population. It ignores the issue that a large percentage of tweets come from spam bots.

As soon as you start measuring sentiment, there is an incentive for an interested party to try sway the results. For example, I could use a spam network to publish opinionated tweets just to obtain a headline in the media (E.g., "95% of tweets agreed with X"). The media coverage gives legitimacy to the manipulated result.

I wonder how many companies have set goals around this sort of sentiment. "Let's increase positive sentiment by 10%". An ethically challenged consultant could easily manipulate results to meet the stated goal.

There is still a place for sentiment analysis and that is in targeting individuals for follow-up. Assuming that the user can be matched to a real consumer, this avoids the issues of statistical manipulation. Though users can still exploit the "complain and get something free" loophole.

I see a lot of similarity between the Color discussions and anything written about Fukushima; a small number of facts are being drawn together to produce wide-reaching conclusions. It is a lot less interesting to say "we don't know all the facts so lets just wait and see how this turns out". These days I find it much harder to find people who are undecided about a topic - everything is polarising.

This strategy may work in the short term but I can't imagine how it will be sustainable. As engineers continue to flock to the hot new thing, they will be leaving a pile of bugs in their wake. The article mentions that developers are responsible for fixing their own bugs but that just won't scale. Once a developer has been there for two or three years, their body of work will have grown so large that they will no longer have the capacity to perform maintenance whilst working on new features. Your example of bugs in fan pages is a problem that will only get worse.

Perhaps they just need to sustain this model long enough to get to an IPO.

A primary reason why a site wouldn't support PMs to markbao@news.ycombinator.com is that there is no access control. The address would get spammed too easily from senders with no affiliation with Hacker News. The current mechanism of only supporting messaging within the site limits this.

A problem that affects all software companies is how they manage their legacy. In a startup, everything is new and you are blazing frontiers. Once established, the legacy code just keeps growing and a bureaucracy is put in place to manage it. Developers are leaving Google for Facebook so they can get things done. You can then imagine where Amazon sits in this journey. Joining a startup is like rewriting everything from scratch.

I would love to read more articles about how mature companies are reinvigorated and revived. It is easy to point the finger at what went wrong and why companies often aren't sustainable but what about the counter-examples that we can really learn from?

When things are in the cloud, they don't have to be in different data centers. Cloud providers are starting to provide tools that give you control over proximity for exactly these sorts of performance issues.

Lotus Notes and Lotus Symphony aren't consumer apps but they both have a pretty big user base beyond typical Eclipse users. Azureus is the first consumer app that comes to mind.

I had initially assumed that whitening creams were used to create a caucasian look - an idea which I found quite repulsive. When a friend explained that it was to mimic the appearance of the upperclass, whose skin colour contrasted with a labourer's, it began to make sense. When thought of as a status enhancer, it doesn't seem that disimilar to tanning..

This article just reinforced how hard it is to build brilliant products inside traditional software houses. The thought of going through several rewrites of a back end and front end, prior to release, would be laughed at.