triztian
Do you have any links to what has been currently done?
EDIT: Found this thread so far: https://discourse.julialang.org/t/statically-compiled-and-st...
Do you happen have any links to the static binary procedure? Or links to the current state of efforts for this?
Or are there steps to produce a binary (much like Go or C or Rust)??
I wish it'd be more popular and preinstalled on servers and macOS.
I'd also say that the write once support on all devices is definitely not a 100% thing. There is definitely a lot of tweaking for adding support to specific platforms and devices (think iPad vs iPhone vs Android Phone vs Android Tablet). I've also found it that its a lot easier (when compared to native development) to create code that needs to be heavily refactored out when adding support for additional devices while also making sure to not braking things on other platforms. This last point complicates development because then you are forced to be familiar on how to test and debug on each platform, making sure that changes or issues fixed on a specific one don't break the other ones; this for sure adds a ton of development and testing time, specially when you go beyond just android phones and iPhones.
Where flutter has shined for us though has been for internal tools that we deploy and for which the UI is not designer-driven or that don't have stringent design and performance requirements.
Now don't get me wrong; I'm well invested in flutter but it does not come without its compromises, specially on iOS being second in line support after Android. It definitely gets you quicker to market with an MVP on more platforms compared to pure native development.
I think it's the wording like you mention, in Lat-Am countries it is common to say "darle seguimiento a las entregas" or "rastrear entrega" as a way to signal that the person is responsible of making sure that things workout well including handling or helping out with any technical or communication roadblocks for the team.
I think we have a good code-quality/speed-to-release ratio with well known tech debt that is actively being cleaned out, that is also tested after refactored out.
Having QA Tester be part of the team makes it really easy to adjust features, adjust the release if an update is needed and it is not passing quite yet quality wise. It also makes it really frictionless specifying what to expect from a ticket/feature and how to baseline test it, the tester also performs some tests of his/her own, the QA tester runs unit, automated UI and performs manual regression tests.
I've been part of teams that have QA testers outsourced as a dedicated independent team and it definitively impacted code quality and the release turnaround, mostly because of delayed communication and mis-alignment on what to test or the expectations of the test.
1. 2 pms - collab and project management questions.
2. Trivia Q&A with 2 devs and tech projects
3. Lunch with Dir. Eng, and senior dev.
4. Whiteboard leetcode with A researcher and a junior dev.
5. Systems design with Dir. Eng and a senior devops
6. Chat sessionr for questions with VP of Eng.
Didn't hit it off with the last interviewer so it was a no-go.
If a take-home is required I'd at least expect a code review over it and focus the rest of the interview process on soft skills rather than trivia questions that are answered essentially by the take-home exercise.
mitmproxy --mode reverse:https://my.privateapi.com -s ./path/to/mockscript.py
It basically boils down to using pyenv, poetry and setting up the pyproject.toml and project src layout.
I read the comments before the article and was expecting a MUCH more complicated content and intricate bash, tool or config setups but it seems straightforward.
I feel everything else is part of getting started into professional software development (git, modern OS, env vars setup, bash or shell scripts, etc) which is it's own right complicated for newcomers.
I think deployment and packaging vary a lot depending on the target deploy env which is why I'm fine with it being left out of the article.
Some companies might no have the internal legal frameworks to hire remote in the US or far less outside the US, as an anecdote a company I used to work for was fully remote but only hired remote on some specific states, this because of tax laws that would vary in each state would complicate their operations. This was a smallish company, less than 40 people.
#!/bin/bash
cd $HOME
# Create project directory
mkdir hellogo
cd hellogo
# Init project modfile
go mod init example.com/hellogo
# Create the main source file
# Uses bash's heredoc
cat << EOF > ./main.go
package main
import "fmt"
func main() {
fmt.Print("Hello world")
}
EOF
# Build it
go build
# Run it
./hellogoI've found this to be a great resource, hope you find it useful:
* http://gromnitsky.users.sourceforge.net/articles/notes-for-n...
if((b != nil)
&&(b->qid.type==a->qid.type)
&&(b->qid.path==a->qid.path)
&&(b->qid.vers==a->qid.vers)
&&(b->dev==a->dev)
&&(b->type==a->type)){
fprint(2, "cp: %s and %s are the same file\n", an, bn);
ret = 1;
}