Well, I don't think the article argues for employees sitting on needles during their working hours, but rather a push back on the very real and opposite trend where excessively fancy and comfortable offices makes employees detached from the actual finances of the business.
As many others are sharing feedback, I thought I’d might add some myself: I would like to have better support for changing roles internally within the same company (ie promotions etc) and in this regard having the month available at least as an option would be great. LinkedIn uses the company as a higher level grouping, then the years/months spent in a certain position.
For me to use this regularly I would have some reason to check in; and I guess either building up “company profiles” where I could see people who work in a certain company or indeed an interesting way to find companies and open positions would be great.
I love the “features” section and the focus on adding people you’ve worked closely with.
As you are - it seems - involved in Quip too, I’m cheeky enough to add some feedback in that product: fix notifications (!) - managing and keeping track of them is close to impossible, make it easier to actually discuss higher level on a particular document (not per line, and the comments in the sidebar disappears quickly) and lastly please add support for collapsing certain sections of a document :-)
Without any precedent on concrete examples of what is legitimate and what is not, this clause in the GDPR is its biggest weakness.
If a company sells something online they only really need your address & name for delivery + credit card details. Then you could argue it is legitimate to use an email to create an account, fair enough. But without precedent it's so easy to just say 'in order to increase revenue (legitimate intrest) we're going to use all emails to send a newsletter, boosting sales'. And then you could use the 'Right to object' in the GDPR as a fallback for your actions.
I know of multiple companies where they prior to GDPR asked for explicit concent during signup for being allowed to send newsletters, but who post-GDPR dropped the concent and use 'Legitimate intrests' to justify it. Basically leaving the individual worse off.
The 'loophole' here would be the definition of 'legitimate intrests', where businesses can defend not giving users a choice in many of these matters due to the activity being critical for the service to work or the business to survive.
I.e. Facebook _could_ argue that users would have to have their data collected and analysed, as this would enable them to sell ads which in turn is their core interest.
Another example could be automatic enrollment into newsletters or data collection/analyzation with the option to opt-out by going to settings. You don't _have_ to give users the explicit consent checkbox during signup if you can defend the activity by it being in your legitimate interests.
Kolonial.no | Software Engineer; Dev Ops; Data Scientist; iOS developer | Oslo, Norway | ONSITE http://jobb.kolonial.no/
Kolonial.no are one of the fastest growing startups in Norway recently valued at ~$180 million after just 3 years of operations. We're enabling users to buy their groceries online and have already thousands of daily customers.
We're unique in that we've built a complete warehouse, logistics, and procurement platform with millions of daily transactions and lots of interesting challenges as automation becomes a more important. This has allowed us to scale and adapt quickly to market and business demands.
Our technology stack is primarily Python, Django, PostgreSQL, HAProxy, Salt, Elastic Search, Celery, SCSS and Javascript + React.js where suitable. You can read more about our stack here: https://kolonial.no/om/teknologi/.
Non-exhaustive list of benefits: a competitive salary; autonomy; warm lunch made by our office chef; new offices in central Oslo; and whatever equipment you would like to develop on. Norwegian is not a requirement, but it is preferred if at least you'd like to learn.
Can't get it to work on Firefox due to it trying to load jQuery from code.jquery.com where the CORS-policy disallows it. Specifically:
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://code.jquery.com/jquery-1.12.4.min.js. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
Norway recently decided [0] it would manually count the votes in the upcoming election (11th of Sep) after it was revealed that the machines responsible for automatic counting were connected to the Internet and full of potential security exploits [1].
Kolonial.no | Software Engineer; Dev Ops; Data Scientist; iOS developer | Oslo, Norway | ONSITE http://jobb.kolonial.no/
Kolonial.no are one of the fastest growing startups in Norway recently valued at ~$180 million after just 3 years of operations. We're enabling users to buy their groceries online and have already thousands of daily customers.
We're unique in that we've built a complete warehouse, logistics, and procurement platform with millions of daily transactions and lots of interesting challenges as automation becomes a more important. This has allowed us to scale and adapt quickly to market and business demands.
Our technology stack is primarily Python, Django, PostgreSQL, HAProxy, Salt, Elastic Search, Celery, SCSS and Javascript + React.js where suitable. You can read more about our stack here: https://kolonial.no/om/teknologi/.
Non-exhaustive list of benefits: a competitive salary; autonomy; warm lunch made by our office chef; new offices in central Oslo; and whatever equipment you would like to develop on. Norwegian is not a requirement, but it is preferred if at least you'd like to learn.
Kolonial.no | Software Engineer; Dev Ops; Data Scientist; iOS developer | Oslo, Norway | ONSITE http://jobb.kolonial.no/
Kolonial.no are one of the fastest growing startups in Norway recently valued at ~$180 million after just 3 years of operations. We're enabling users to buy their groceries online and already have thousands of daily customers.
We're unique in that we've built a complete warehouse, logistics, and procurement platform with millions of daily transactions and lots of interesting challenges as automation becomes a more important. This has allowed us to scale and adapt quickly to market and business demands.
Our technology stack is primarily Python, Django, PostgreSQL, HAProxy, Salt, SCSS and Javascript + React.js where suitable. You can read more about our technology stack here: https://kolonial.no/om/teknologi/ (Norwegian only)
But then you're working in a bigger business where you do actually need to interact with managers and internal/external stakeholders. And they're all asking you: «When can you deliver?».
Yes, estimating is hard. It's impossible really, but everyone knows this and accept the consequences of delayed deliveries and blocking events. But they want status updates and delivery schedules all the same.
Pointless exercise maybe? But in real life and in business actually having someone thinking longer than three days ahead is usually a necessity, in my experience.
I agree though that you should minimize the amount of pointless meetings and solve blocking issues as they come - this is more a sign of a good tech lead and healthy work environment rather than weaknesses in the Scrum methodology.
Maybe it's just a sign of todays technology reaching some sort of early maturity?
You don't see many new revolutionary cars around either - or at least they all conform to the same idea having four equally sized wheels, 5 seats and a round steering wheel. I'm guessing 100 years ago you saw many alternative "paradigms" in the car making domain too, before our society settled on something that worked for the majority of us.
Scaleway is a highly interesting player in the IaaS market as they're one of the few currently that are offering ARM based servers. Will we see more ARM servers the next couple of years from more vendors?
The difference between them, which also could explain the AOL-like speeds with Gogo, is that Row 44 used a satelite dish whilst Gogo communicates with ground radio towers. The obvious advantage of Row 44's approach, which is also highlighted in the video, is that by using satellites you can continue providing internet over remote areas and oceans.
Looks like a very interesting project which I'll keep a keen eye on. We're probably not ready to switch our entire stack from Mesos to Lattice though, especially considering you're missing some important bits such as external service discovery etc. (by the looks of it)
We're currently doing Marathon on Mesos with gliderlabs/registrator which syncs Docker and Consul - and then we're using consul-template + HAProxy for exposing applications externally. Works quite nice.
The differences (and advantages) between Lattice and Mesos could've been made clearer too I guess, although your docs and FAQs are quite nice.
Are there many of you actually using Chronos in production? I'm not sold that this project will still be with us in a couple of years..
I'm not saying the idea is bad, but comparing the developer community of Marathon with Chronos you see some obvious differences in commits, developers, issues (and responses), releases etc.
We've been using it in conjunction with Marathon and Mesos, and my impression is that it's a now half-dead project riddled with bugs (especially in the web UI) and I'm unsure whether we should invest more resources and infrastructure around this project.
Aurora does look interesting. But Apache doesn't have a much better reputation, and I'm not particularly keen on going away from Marathon. Any DevOps engineers with container/mesos infrastructures wanting to chime in?
This does not solve the two issues I have with doodle:
- The creator is the only person with permission to add alternatives (both for their "Make a choice" and "Find a date" features)
- There's no way to limit the number of responses from each participant - e.g. each user need to select their 3 most preferred time slots.
Also this app, contrary to Doodle, requires you to select time slots, whilst with Doodle one can just decide on dates (and the time is optional). I also quite like the "Yes/No/If-needbe" feature that Doodle provides and I'm disappointed about the binary view of event planning this application takes.