I want to create an GUI application, that would communicate with Asterisk server and provide functions, such as call forwarding, originating calls, etc.
I wanted to use Kivy (Python GUI framework), but there here is so many different tools (AGI, AMI, FastAGI) and libraries (Pyst2, StarPy, etc.) to manage asterisk, that i don't even know where to start.
I have already written some code (using Pyst2 asterisk manager) but I have a feeling, that this is not the best solution, as said application should be able to have multiple instances open simultaneously and AMI would be too messy for that purpose.
Could someone give me some advice or suggestions what tools would be best to use in this case?
You can start from nice book, like ORelly "The future of telephony".
There is no way do something really valuable without know of asterisk dialplan. All that technology used for different things.
Related
I've found an example: https://medium.com/velotio-perspectives/a-comprehensive-tutorial-to-implementing-opentracing-with-jaeger-a01752e1a8ce
I have a pretty large codebase and I really don't want to modify every function by adding a line like ' with tracer.start_span('booking') as span:'. Is there any way to do it?
Thanks in advance.
Jaeger is a distributed tracer, inspired by Google's Dapper paper, and so it is mainly used for tracing communication between different processes in a microservices / distributed system architecture, not so much for portions of code inside an application.
The way Jaeger is introduced into most applications is to integrate it into the part of the application that is receiving requests from the network. For example, if your Python application is receiving HTTP requests using Django or Flask, or other types of requests (e.g. gRPC) using some other framework, there will probably be a project somewhere on the internet that lets you hook Jaeger into your framework with a couple of lines of code. For the most popular frameworks, the Jaeger docs point to opentracing-contrib as a good source for these "client libraries".
While making extra tracing calls inside an application is not unheard of or discouraged with d.tracers, it's not something that tends to happen a lot, because d.tracers are typically used in microservices environments where the interactions between components are more important than what's happening inside the components.
If you do want to create tracing records inside an application, then it would be very unusual to do tracing of every single function. Instead, tracing inside an application would typically be done at the boundary of components in a modular monolith, i.e. when one component calls into another component.
Lastly, if what you really want is performance analysis of your single Python application at the level of each function, and you don't care about it's interaction with other applications in your system (maybe you only have the one?), then Jaeger is probably not the right tool. In that case, you would probably want to look for an Application Performance Monitoring or APM tool that works with Python and suits your needs.
We have a large, interactive R program that we would like to interface with Shiny. There is a small Python program we would also like to create an interface for alongside it. There are no dependencies between the two sets of code, but as a research institute we'd like to provide a common interface for the two programs might be accessed by the same users. What is a good way to go about it? Is it better to consolidate under python/Django and use rpy2, or make system calls to the python program through R's Shiny interface? Are there better alternatives, or recommended practices?
Django would be an overkill.
rpy2 is a good option for small modules containing simpler methods
flask is another good option for python's side. Programmers can transmit files or even build simple web-interfaces. I prefer this method. Tell your students/collegues to define fixed APIs and response format [JSON/XML] and even a new scholar wouldn't have to spend times thinking about how to make it work. Just tell him the APIs and work with it just like Alchemy etc interfaces.
Shiny is a good option for building web-interfaces on R side. A quick tutorial that works. http://shiny.rstudio.com/tutorial/lesson2/
I am going to write configuration tool for my Ubuntu based system. Next I would like to write frontends (text, GUI and web). But it is the most complicated project I wanted to write and I am not sure about general architecture I should use.
At the current I have functions and classes for changing system config. But these functions will probably grow & change. #Abki gave me advice how to write interface for frontends. I am going to make base classes for this interface but I don't know how to connect it with backend and next with frontends. Probably I should use design patterns like fasade, wrapper or something else.
It looks like (without interface_to_backend layer):
I don't care about UI and functions to change system config now. But I don't know how to write middle layer so It would be easy to connect it with the rest and extend functionality i the future.
I need general ideas, design patterns, advices how to implement this in Python.
I'm not sure this is entirely appropriate for SO but I'm intrigued and so I'll bite. As a rubyist I can't help much with the Python but here is some opinion on pattens from my experience.
My initial suggestion is you should review a few of the contenders out there. Specifically I'd be looking at cfengine, chef and bcfg2. They each tell a different story but if I'd summarise I'd say:
Chef has a lovely dsl syntax but is let down by a complicated architecture
bcfg2 is written in python but seems to have an annoying tendency to use XML :(
cfengine has the strongest theoretical underpinnings in promise theory (which is v.interesting BTW) but is C based.
Wikipedia also provides a pretty impressive list of configuration management tools that you will find useful.
In regard to designing your own tool I'd suggest there are three principles you want to pursue:
Simplicity, the simpler you make this the better. Simple in terms of scope, configuration and use are all important.
You'll need a single way to store data, you need to be able to trace the choices as they are made and not trample other people's changes (especially in a team environment).
Security, most configuration management tools need root privileges at some point. So you need to make sure that users can trust the code they're running.
You could use Fabric with Python as described in the article Ubuntu Server Setup with Python Fabric
The Wikipedia article at Comparison of open source configuration management software has several other tools that use Python to do this.
I like the approach taken by SALT.
If you write the GUI, text/CLI, and Web interfaces using Python, they can all use the same Python module. That way a change in one interface transparently affects the others. Plus all of those are in Python's area of strength.
We have around 250 identical linux server which runs a business critical web application for a bank. Basically we do a lot of scripting work but now i want to centralize that only in one location. That means run on one server and and deploy it in many. I know you guys must be thinking that this is an easy task and can be done with a shell script. But again we need to create many different different scripts to do our work
I know python has a big library and this can be possible but i dont know how. To cut in short i need all scripts in one file and based on the argument it will execute it according.
For example in a python program we have a function where we can mix them to perform different result.
So you please let me know how to go about it
This is a very general question, so I'll respond with two different frameworks that are made using Python to facilitate bulk system administration tasks.
func - Func is part of the
Fedora project and so is specialized
to their architecture. If your hosts
are all RedHat/CentOS based, this is
the solution for you.
fabric - Fabric is more generic
but does generally the same thing at
a high level. If your environment
is heterogenous (full of different
types of systems/distributions),
this is probably what you want.
You could also try any of the distributed computing packages. Pyro is one of them that might interest you.
We are in the process of standing up a UI on top of a python system. This is all throw away code, so we want something quick, yet presentable.
We will have a couple of "interfaces" but they will be of two types. One will be control, it will basically be sitting on top of a python thread, and accepting requests from the user.
The other will be more of a display screen that will need to be able to display images, and some classic "grid views" of text to the user.
We pretty much know we could* do all of this in HTML but wasn't sure what would be the best way to interact with the core python code?
Anyone know of a good UI python presentation layer? Since we know we can do all of this in HTML/Jquery pretty quickly, we are also open to suggestions on how to integrate this with a web server..
Any suggestions? Really interested in finding out if there is any way to use python as the back end to a webserver.
Let me know if you all need more information.
I like wxPython. The demo application is excellent and lets you browse, tweak and re-run the code right in the demo.
We have found the DJango meets our needs. It is a pretty slick mvc style python web stack. Really is easy to use, and very quick to develop in. I will say that the ORM layer is a little young so it is hard to do some simple queries, but luckly since this is throw away code we can just use native sql.
Tkinter is probably going to be the solution you can use quickest. Its API is simple and straight-forward, and you probably already have it installed.
As the other 2 classic Python GUI options have been given already, I feel duty bound to suggest PyQt :)
Using QT Designer I've found it much simpler than TKInter to get some basic GUIs up and running. Build your GUI up in a WYSIWYG way, then hook it up to the back-end logic. I've also found that the large amount of C++ help on QT available on the interent usually translates more or less directly across to PyQt. The resources available for TKInter are IMO pretty obtuse, and simply stop as soon as you want to do anything more interesting than Hello World. YMMV.
The Rapid GUI Programming with Python and QT book is a fantastic resource. Had me programming real applications in no time.