Python is known as a dynamic, strong-typed language. Most developers love it but some feel mad without type checking or type-hinted auto-completion. In Python3.5, Type Hints is introduced to further delight developers who want those features.
Type Hints offers type checking on function parameters, return values and class attributes, as if it’s static-typed. If you pass something does not match the expected type, a warning will be given.
According to The Theory of Type Hints, here’s an example showing how the rules work out in practice:
Say there is an
Employee class, and a subclass
class Employee: ...
class Manager(Employee): ...
Let’s say variable e is declared with type
e = Employee() # type: Employee
Now it’s OK to assign a
Manager instance to e:
It’s not OK to assign an
Employee instance to a variable declared with type
m = Manager() # type: Manager
m = Employee() # Fails static check
Now, suppose we have a variable whose type is
a = some_func() # type: Any
It’s OK to assign
Of course it’s also OK to assign
Employee e to
Get crash reports from Sentry
We have been using Sentry for collecting crash reports and stack traces for our front-end js, Python, and Rails applications. It is reliable with affordable pricing. Simple to setup with it’s open-source SDK.
However, there’s a fundamental problem when it comes to iOS.
What? No symbolized data returned?
Sentry only returns the crash report with a piece of memory address but not a meaningful method name.
As an iOS developers, you should have noticed that it requires a dSYM file to symbolize the stack trace. It helps to identify these addresses with the appropriate dSYM file.
We thought we can upload dsym files and get symbolized information returned when Sentry claims it works on iOS.
Unfortunately, it is not the case:
No one can understand the iOS Stack trace with memory address only. Proper support of dSym is needed.
(BTW if you can debug with memory address, please consider joining us.)
One of the possible solutions is to fork a piece of Sentry code and get our hands on it, but we don’t want to get into the complexity.
Instead, we write a micro service that will reply to a Sentry notification with de-symbolized stack trace on Slack, here is what we did.
… and it didn’t benefit that much.
Everyone in the DevOps community should have already heard about Docker.
There are always sysAdmin coming around and telling you how Docker has made his life easier, how well the automation goes or how lightweight the containers are…
So, what is Docker trying to solve?
Basically, Docker wraps up your application and all the dependencies required into a complete filesystem, that becomes a Docker Image. The next step is all about shipping this container to your production infrastructure, let it be AWS, Heroku or other servcies.
Back in the Pre-Docker age, every SysAdmin implements his own solution to package and deploy applications.
A small scale online shop might use git to deploy code and virtualenv to contain applications in an isolated environment. There were also existing solution providers – Heroku, Elastic Beanstalk, Google AppEngine and others services, having their own proprietary way for packaging and deploying applications.
Now, all the configurations and environment settings are standardized in the Docker Container, which actually saves loads of time for developers dealing with the repetitive setup and maintenance.
As mentioned in our previous post, at Oursky, we use Travis CI to build, test and automatically deploy our software applications. While the command line control has been super developer-friendly, we should also care about the feelings of less technical roles in the team, say PM, QA, and Designers. 🙂
Hence, we introduced Chima and Faseng, both are bots to assist the deployment process. (For cats in our office, see this post.)
What is ChatOps?
We learnt about this from GitHub — its open source chat bot (Hubot) for ops: automating deployment, graphing, monitoring, provisioning, tweeting, and many other things.