Perhaps "uncapped" rather than "unlimited" would be a better term for us to start using
109 karma · joined May 20, 2011
<input id="i">
<button onclick="l.textContent='Now do '+i.value">Do This</button>
<button onclick="l.textContent='Do nothing'">Do Nothing</button>
<label id="l"></label>And I ended up here: https://www.masswerk.at/keypunch/ - virtual keypunch machine.
It seems that commands are sent as 11 bit values, 50 per second, and the command to send the "Ignition Off" value is any value over a set threshold.
From the doc: "A such, a single bit error would be sufficient to modify the 'Ignition ON' signal value so that it exceeded the 'Ignition OFF' threshold."
(This has now been fixed by the manufacturer so that there must be 10 consecutive Ignition OFF commands)
[1] https://www.tekever.com/models/ar5/ [2] https://www.flightradar24.com/GTEKG/32088166
(Tech Support Cheat Sheet)
This exactly
From this: https://www.russell-cooke.co.uk/insight/briefings/2020/intel...
"The general position under English law is that IP rights created by an employee within the course of employment automatically belong to the employer; where there is any doubt as to whether an employee or their employer owns IP rights, the relevant legislation largely favours employers."
"If material which includes IP rights is created outside office hours and/or using the employee’s private resources this may give rise to arguments that the rights belong to the employee rather than their employer, but that is not decisive. The fact that work is done outside normal working hours does not necessarily mean that the work is not done in the course of employment as, for many employees, there is often no clear demarcation of the hours of work."
"The key question to be asked is whether the work was the kind of work which the employee was employed to do i.e. whether it was within the scope of their employment. Could the employee have been ordered to do the work and would it have been a breach of contract for the employee to not do it? The terms of any contract of employment and job description will be relevant, however, these (and duties more generally) often evolve in the course of time and it may therefore not be appropriate to rely on them exclusively."
IANAL, but my reading of that is that if I wrote a novel about unicorns and rainbows, that wouldn't be owned by the company, but if I wrote software, it would.
The email had some vlaid account fogbugz account details, so it's at least coming from their database...
[1] https://github.blog/2017-03-21-work-life-balance-in-employee... [2] https://github.com/github/balanced-employee-ip-agreement/blo...
The interview went well, the coding test was good. Finally, I were just chatting with the CEO, and he asked "So you're ok with spending 2 years on site in Kazakhstan?"
Needless to say we both agreed that it was a wasted interview and that the recruitment agency should have mentioned the Kazakstan bit...
https://stackoverflow.com/questions/6355300/copy-to-clipboar...
It was something like "when a link starts getting multiple posts on hacker news that's when we know we've hit on something..."
I'd not heard about hacker news until that point. I was probably hanging around codeproject.com. Since then I lurk almost daily, and am always amazed by the breadth and depth of articles and commments, both tech and non tech.
Reduced need to actually own a car, and fewer cars on the road (or parked) as empty car capacity can be fully utilised. Of course the lifespan of an individual vehicle will be reduced.
I like to do this (explore the codebase) with any new code. My approach is to pick a piece I'm interested in (eg, auth, orm, some api integration), and either: a) see if I can just develop that bit from scratch using the codebase as example - that really helps with my understanding of the required components that get that bit working, or b) delete non-relelvant bits of the codebase until just that bit's left and it's not broken. Then you can tweak, extend, explore, experiment, and slowly add other bits back in.
Point b) works well with tearing apart smaller github projects to see how the bit I'm interested in work, less so with a large codebase.
But tbh, yes, it's pretty much sink or swim. I expect to be put on projects with little backgroud knowledge and expected to get myself up to speed and be productive. Anything else is a bonus.
Where structured training has really helped is in the softer skills, like project management, problem analysis etc. This makes it easier to communicate common concepts, thoughts etc to people who aren't just devs (eg, being able to put a timeline on a problem, identify a change point, and perform root cause analysis that leads you to fixing a fundamental bug). These are skills that you _could_ absorb through good company practice, but better to spend a day learning and be on the same page.
Might be worth adding a note saying "approx $18 USD" line to the pricing message.
https://www.npr.org/sections/thetwo-way/2013/01/16/169528579...
https://www.kentonline.co.uk/folkestone/news/floating-ship-a...