caspar

As I remember it, ads/malware trying to look like install (or download) links have been common for the last 10 years - to the point of training me to ignore any image that has the word "Download" in it. Choco helps work around much of that.

It's more concerning to have official installers contain adware/malware though.

Similarly, I've been using Modeless Keyboard Navigation[0] (a vimium fork to remove the normal/edit mode distinction) for about 2 years now, and it works wonderfully for navigating to links via keyboard.

0: https://handsfreecoding.org/2017/11/22/extensions-now-availa...

As amusing at it is to imagine, their team page only lists 3 developers[0], so I bet that turnover does not happen particularly frequently!

[0]: https://sqlite.org/crew.html

In addition to what other responders have said, another factor is that if you're a top (or better than average) performer in X, then the default assumption will be that you'll be a top (or better than average) performer in Y, given some time to ramp on Y.

That may or may not be true, of course, but it's an element in your favor either way!

(though fwiw, in my time as a past manager, I found that significant effort counted for a lot - it's cliche but folks who consistently put in extra effort and worked their butts off improved faster than those who relaxed, so they would soon exceed folks who relaxed, even if they had much less of a head start.)

Hey, unrelated, but you might want to check how your home page's moving headline behaves on different window sizes. For me at about 850px and 1470px, the words that change at the start of the headline cause the content below to pop up and down every few seconds (FF on Win).

About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence).

Jira (both Cloud and Server) does cache permissions, heavily. Jira effectively has a local cache of user and group relationships for all users who have access to a given blah.atlassian.net Jira, and caches lookup results in a shared cache too. It's complicated by having well over a hundred thousand active Jira sites spread over several hundred stateless servers, which does make effective caching a bit trickier.

AFAICT Jira Cloud's slow feel currently stems largely from the front-end, amplified by the debacle that is modern front-end engineering. It's tricky to get 300+ engineers to ship fixes and enhancements in a multi-million line codebase over 15 years old on a good day. Feature creep in design systems, constant ecosystem churn, and poor build tools all conspire to make it that much harder to prevent performance regressing.

But even knowing all that - yeah, I wish that Jira's performance was 5x better too :)

Disclaimer: am still employed by Atlassian but all views are my own, things may have changed a bit since I haven't touched any Jira code in ages, etc.

I see this too - see https://imgur.com/a/029OQCn if the parent's screenshots are not enough.

patio11's post over at https://training.kalzumeus.com/newsletters/archive/selling_s... provides a bit more color too.

Also, a friend of mine used FE International to sell a moderate side project of theirs and they were very happy with using FE as the brokers.

IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient.

A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise.

But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists.

(You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)

Talon actually uses Mac's built in STT if you don't have Dragon.

James from http://handsfreecoding.org/ was working on a fork of Dragonfly[0] to add support for Google's speech recognition, but I'm not sure if he still is. There are several barriers to that working well though: additional latency really hurts, API usage costs and (as far as I know) an inability to specify a command grammar (Dragonfly/Vocola/Talon all let you use EBNF-like notation to define commands, which are preferentially recognized over free-form dictation).

[0]: https://github.com/dictation-toolbox/dragonfly

Already available in the form of the Tobii 4C for approximately 150 USD. Only accurate for most people to about a circle with diameter of about an inch on the screen though, and it feels strange to use it for an FPS.

Have you tried using the Blender 2.8 release candidate UI though? As someone with approximately zero artistic skills and minimal 3D background, I was also turned off by Blender's inscrutable UI patterns 10 years ago.

But with the 2.8 RC news on HN last week I recently tried it again and I have to say that now it seems like the UI is pretty decent. Left click select, a move tool that works like every other move tool in paint, a clear hierarchy view with obvious nestable layers - it seems like many of the weird things I remember (like "drag the divider between the viewport and the menu bar down to see a secret option pane") are gone or redesigned now.

Check out https://www.youtube.com/watch?v=jBqYTgaFDxU for some example usage or https://www.youtube.com/watch?v=lPVpg4_POww for a preview of the UI/UX changes.

FWIW Atlassian's perspective is generally more like "they don't have much money yet, so let's get them while it's easy to get them". Small companies grow into big companies, and small single-team deployments tend to spread into big whole-company deployments - but small customers are much easier to get than large customers :)

Disclaimer: long time Atlassian employee but all words are my own.

Disclaimer: long time Atlassian employee but I do not work on Jira/Conf/Bitbucket & all words here are my own opinions.

A major problem is that many deployments of Atlassian products are Server deployments (i.e. not Cloud), which means there's basically the embedded Lucene engine and that's it; anything else starts hurting either performance or deployment options at scale. And most Server customers have a much greater interest in scaling (while keeping servers performant & easy to run) than getting tweaks to search algorithms - in particular many customers refuse to upgrade unless there is a major bug fix or performance boost they're going to get.

On the Cloud side, for better or worse the focus has mostly been on letting people find their work, not find new content they haven't seen before. For example, Confluence's My Work tab (or similar - I forget the exact name), or the search in the cross-product https://start.atlassian.com/ are both useful for getting back to things you've seen before. Hopefully some day we'll finally make some headway on the "I don't know what I'm looking for but I know how to describe my problem" use case.

And just to buck the trend, search works as advertised in the Atlassian product I work on, statuspage.io ;) (but then our search use case is straightforward and rare enough to just use elasticsearch with some minor tweaking).

> The problem seems to be the provision that a tech worker can be coerced by the Australian Government into creating a backdoor, and they are not authorised to disclose it to their employer.

> Is this true ? There is no way I am hiring an Australian citizen then.

No. The request or notice is served to the company, not the individual, so the company is not left in the dark.

There has been a lot of poor reporting about this law; roughly speaking, there are 3 types of requests for data allowed:

1. Technical Assistance Request - "give me this data please". Optional, no penalty to anyone for not complying.

2. Technical Assistance Notice - "give me this data if you can, or else..". Mandatory, penalty to the company if they can comply but do not comply.. but if the company would have to build a new thing to comply (e.g. they do not have the decryption key and there's no backdoor), then there's no penalty and they do not have to comply.

3. Technical Capability Notice - "give me this data or build a way to give me this data, or else..". Mandatory, and a penalty to the company if they do not comply. If they can't do the thing yet, they need to build a backdoor, unless doing so would introduce a "systemic weakness".

In all cases, it's the company being targeted. Individuals in the company only become liable for penalties if they leak information to people not involved in the investigation.

Yes, it's still a bad law that was rushed through with too little discussion. Yes, there is too much room for interpretation and too little oversight. (And yes, Australian tech companies like Atlassian are lobbying heavily to improve the situation[0][1][2].)

But we're not at the point where it's reasonable to blacklist Australian tech workers yet, thankfully.

Source: I am an engineering manager at Atlassian, a major Australian tech company; there has been a lot of internal discussion and guidance from our founders and legal team about this.

Disclaimer: I am not a lawyer, this is not legal advice, etc. Also, I am an Australian citizen.

[0]: https://www.theaustralian.com.au/business/technology/scott-f...

[1]: https://www.afr.com/technology/web/security/atlassian-leads-...

[2]: https://ia.acs.org.au/article/2019/tech-industry--fix-the-as...

Just chiming in to second all of this. Best combination of comp, culture & growth opportunities in my career.

Disclaimer: am a hiring manager at Atlassian, so obviously I am biased (though currently hiring in the US market).

I'm not the person you're replying to, but it seems to me that there may be an example of a common misconception about Big-O in your comment here:

> Big-O is literally a straightforward way to write the formula [describing] best/avg/worst case time or memory of a program

Technically, Big-O notation should only be used to provide an upper bound on the best/avg/worst case[0]. And typically people only use it to discuss the worse case or average case, just because talking about the upper bound on an algorithm when its inputs are restricted to its best possible inputs is typically much less useful.

But providing an upper bound is not quite "writing the formula" (giving a complete picture), because you haven't specified the lower bound (Big/Little-Omega) - very loosely speaking, if you only ever talk in terms of Big/Little[1]-O, you've only provided half the picture. Of course to be fair, Big-O of an algorithm is the side of the picture that is way more likely to bite you in production!

Disclaimer: not a mathematician, so salt to taste :)

0: https://stackoverflow.com/a/12338937/775982 1: https://en.wikipedia.org/wiki/Big_O_notation#Family_of_Bachm...

Internal and external apps are both deployed on the same PaaS. Only difference is that internal apps aren't reachable "outside the VPN"; when it comes to building your service, it's an extra line of yaml in your service config. There's a network engineering team who works with the PaaS team to make that happen - it's definitely a nice luxury of a big company that you don't need to worry about setting up VPCs etc yourself.

The actual PaaS relies pretty heavily on AWS Cloud Formation - it predates swarm, mesosphere, kube, etc. So when we deploy a new version of a service, it's really "deploy an auto scaling group of EC2 instances across several AZs fronted by an ELB, then there's an automatic DNS change made which makes the new stack of EC2 instances live once the new stack is validated as working". The upside of the one service per EC2 image approach is no multi-tenancy interference - downsides are cost and it takes a bit longer to deploy. There's a project underway to switch compute to being Kube-based though, so that's promising.

All this is apples and oranges though - solns for big companies don't make sense for a 1-person shop. I still have side projects being deployed via ansible and git pull instead of Docker, because it hasn't been worth the ROI to upgrade to the latter.

Re asparck - yeah, it was my personal site but I struggled to find the time to work on it. In the end I decided it was better to have it offline than terribly out of date, but hopefully I'll resurrect it some day.

Engineering manager (& previously a developer) at a ~2k developer SOX-compliant company chiming in here.

We have a platform as a service team which maintains our PaaS infrastructure (think an internal version of Heroku), and they are the only ones who can SSH into any production systems (<50 engineers, I'd guess).

Engineers write the code (mandatory green build and peer review required before merge to protect against bad actors.. but that's just good engineering practice too!), build their own deployment pipelines on Bamboo or Bitbucket Pipelines to push up code & assets to a docker registry, and ultimately the deployment pipelines make some API calls to deploy docker images. Engineers are also responsible for keeping those services running; most products (such as Jira, Confluence, Bitbucket, etc) also have a dedicated SRE team who are focused on improving reliability of services which support that product.

The vast majority (95%) of our production issues are troubleshooted by looking at Datadog metrics (from CloudWatch & services publish a great deal of metrics too) and Splunk (our services log a lot, we log all traffic, and the host systems also ship their logs off). Fixes are usually to do an automated rollback (part of the PaaS), turn off a feature flag to disable code, redeploy the existing code to fix a transient issue (knowing we'll identify a proper fix in the post incident review), or in rare cases, roll forward by merging a patch & deploying that (~30 mins turnaround time - but this happens <5% of the time). Good test coverage, fast builds (~5 mins on avg), fast deploys, and automated smoke tests before a new deploy goes live all help a lot in preventing issues in the first place.

It's not perfect, but it works a lot better than you might expect.

See https://github.com/alex/what-happens-when

IIRC, TripleByte only gets their finders fee once (if) the candidate makes it through 3 months of employment.

(Of course, you can argue that 3 months of employment isn't enough - but it's a lot more performance data than a bunch of interviews gives.)

What's special about it is that you have terabytes of data to keep available, and at scale git does not play well with technologies like NFS or cloud object storage like S3, so each major provider either pays a lot of money to specialized vendors or has homegrown solutions to deal with the problem.

So on top of your usual problems with keeping a cloud service up and running, you also have that git IO problem to contend with, and to rub salt in the wound, that wrinkle also makes it difficult to fully adopt many "standard" cloud architectures or vendors (such as AWS) which work for non-IO-heavy applications: you always have this major part of your infrastructure that has this special requirement holding you back at least partially (and that can hurt your availability for related services which are not even IO-heavy).

(That said, it's hard to guess whether that was the problem, a contributing factor, or unrelated entirely based on the details provided here.)

source: I work at Atlassian (though not on the Bitbucket team) and occasionally chat to current and former Bitbucket devs on this topic.

Consider http://www.daemonology.net/hn-daily/ - I've been keeping up using this for years.

> An empty string is "no user supplied data" and a null is "no value has been given at all"

I assume you meant "an empty string is user supplied an empty string as data".

That aside, you wouldn't normally switch that option on for a field (notice the default is false).

However, Oracle DB stores empty strings as indistinguishable from NULLs[0], so an ORM supporting Oracle DB may want to have some support for converting "empty or null" to an empty string at read time (notice the Oracle specific caveat in the docs in your link).

Once you have that, I'd guess the thinking is that you may as well let devs opt into that behavior (bear in mind that sometimes you're in the position of developing a new app against an existing db, that may or may not have another legacy app reading/writing from it at the same time).

0: https://stackoverflow.com/questions/203493/why-does-oracle-9...

You should note that "cargo clean" causes dependencies to be rebuilt next build as well; a regular "cargo build" would only re-compile your module and re-link with already-built dependencies, and so should be a fair bit faster.

Having a bit of fun with the building lights during that hackathon: https://twitter.com/sebr/status/674917395798949888

(Disclosure: am an Atlassian employee, though not in the photo or that team.)

Minor correction: SBT's dependency management is based on Ivy's not Maven's.

And for those working in Scala and building with Maven still, I second the recommendation to download & run Ivy, turn on the useZincCompiler option in maven-scala-plugin's configuration, and enjoy substantially faster build times (and automatically falling back to a normal build if Zinc isn't running). You don't even need to specify a scala home directory for Zinc like it claims; scala-maven-plugin will tell Zinc to use the Scala libs from your Maven repo.

The criteria for having to register to collect GST for the government is something along the lines of "your business turnover exceeds $50,000 per financial year". I haven't been there, but I believe it's about as simple as you say; get an "auskey", and then you can do large amounts of the paperwork online.

I'm a bit late to the party, but the article is misleading.

Atlassian is considering changing its corporate structure so that its parent company is in the UK. Reasons include tax advantages and making the company more attractive to investors in light of a possible future IPO. Supposedly there are very few international companies listed on a US exchange which have their parent company in Australia, which means Atlassian would be a riskier investment.

That may involve having a few people in an office in the UK, but engineering (and company) headquarters would remain in Sydney, Australia.

Nobody would be losing any jobs over this, and Atlassian would still be trying to hire a boatload of developers in Australia.

Source: Scott Farquhar (co-CEO) at the December All Hands meeting (I work at Atlassian).

Edit: should probably point out that this is all "may"s and "would"s because it's up for a company-wide vote in the next few weeks - I have a ~500 page information booklet sitting on my desk.

Not to detract from your overall point, but, as an IBMer, I can assure you that - while my full-time employment contract says max 37.5 hours - the reality is that at least 40 hours are expected.