Plasma is a user interface framework developed by KDE that can be used for desktops, smartphones, tablets, and media centers. It provides a unified API and allows any component, such as desktop widgets, to be used across different form factors. Plasma uses a plugin model where everything is a plugin, including desktop icons. It includes components for data visualization and editing. Plasma Mobile aims to provide a consistent yet optimized experience across different mobile devices using a concept of activities and profiles tailored for smaller screens and limited hardware.
KDE Plasma in your pocket.
Presentation by Alexis Menard held during Bossa Conference 2010 in Manaus.
Read more at http://labs.trolltech.com/blogs/2010/02/28/tokamak-4-the-kde-plasma-meeting/
http://qt.nokia.com
http://www.bossaconference.indt.org/
KDE Plasma in your pocket.
Presentation by Alexis Menard held during Bossa Conference 2010 in Manaus.
Read more at http://labs.trolltech.com/blogs/2010/02/28/tokamak-4-the-kde-plasma-meeting/
http://qt.nokia.com
http://www.bossaconference.indt.org/
DocDoku: Using web technologies in a desktop application. OW2con'15, November...OW2
The DocdokuPLM is an open-source platform allowing its users to manage their product's lifecycle, from design to maintenance. The main application is built upon RequireJS and BackboneJS librairies for the front-end, and JEE for back-end. The GUI is quite complete, and may won't fit for all users involved in the process. This is especially the case for CAD designers who just need to commit their changes without having such a rich graphic interface. To answer this need, we developped a desktop application, interfacing our server with the CAD designer's file system : the DPLM.
First, we developped a command line interface, which is very lightweight and really great for advanced users. However providing a GUI which could interface with the CLI and allow the user to manage multiple files upload at once was more than needed.
Providing a consistent user experience across different platforms has been one of our challenges in the context of our application. The choice of a web framework was then a natural choice. But how could we get it run within a desktop application ? Node-Webkit brought us the ability to interact directly with the user's file system and embed the app in a webview, letting us the choice to use any web framework we wanted to use.
In this talk we will describe our experience developing a reasonably large web application for administrators, consumers and mobile devices using Google's Cloud platform "Google App Engine" and the "Google Web Toolkit" for an AJAX user interface. It will share our decisions made, experiences and learnings in the process and cover areas such as Scalability, Data Storage, Multi-Tenancy, Portability and avoiding platform lock-in, developing for multiple form factors and Bookmarklet development.
Bighead: Airbnb’s End-to-End Machine Learning Platform with Krishna Puttaswa...Databricks
Airbnb has a wide variety of ML problems ranging from models on traditional structured data to models built on unstructured data such as user reviews, messages and listing images. The ability to build, iterate on, and maintain healthy machine learning models is critical to Airbnb’s success. Many ML Platforms cover data collection, feature engineering, training, deploying, productionalization, and monitoring but few, if any, do all of the above seamlessly.
Bighead aims to tie together various open source and in-house projects to remove incidental complexity from ML workflows. Bighead is built on Python and Spark and can be used in modular pieces as each ML problem presents unique challenges. Through standardization of the path to production, training environments and the methods for collecting and transforming data on Spark, each model is reproducible and iterable.
This talk covers the architecture, the problems that each individual component and the overall system aims to solve, and a vision for the future of machine learning infrastructure. It’s widely adapted in Airbnb and we have variety of models running in production. We have seen the overall model development time go down from many months to days on Bighead. We plan to open source Bighead to allow the wider community to benefit from our work.
Building a Pluggable, Cloud-native Event-driven Serverless Architecture - Rea...Dan Farrelly
Building out Reactive systems can be a lot of work. There’s a lot of infrastructure to set up and designing a system to be resilient, responsive, and elastic requires experience and time that not every team has. We built Inngest to be an open source, cloud-native system that enables anyone to build Reactive architectures. Designed to be pluggable with your favorite messaging service like Kafka, NATS or PubSub and your favorite container orchestration like Kubernetes, Nomad, or ECS. We’ll walk through how the system was designed, how you can deploy it yourself, and the plans to make it runnable on any cloud (and even your laptop!).
[WSO2Con Asia 2018] Architecting for Container-native EnvironmentsWSO2
This slide deck explores architectural choices for making applications and integration services first class citizens in a container native environment.
Learn more: https://wso2.com/library/conference/2018/08/wso2con-asia-2018-architecting-for-container-native-environments/
“Node's goal is to provide an easy way to build scalable Network programs”
Asynchronous i/o framework
Core in c++ on top of v8
Rest of it in javascript
Swiss army knife for network Related stuffs
Can handle thousands of Concurrent connections with Minimal overhead (cpu/memory) on a single process
It’s NOT a web framework, and it’s also NOT a language
• Created by Ryan Dahl in 2009
• Development && maintenance sponsored by Joyent
• License MIT
• Last release : 0.10.31
• Based on Google V8 Engine
• +99 000 packages
DocDoku: Using web technologies in a desktop application. OW2con'15, November...OW2
The DocdokuPLM is an open-source platform allowing its users to manage their product's lifecycle, from design to maintenance. The main application is built upon RequireJS and BackboneJS librairies for the front-end, and JEE for back-end. The GUI is quite complete, and may won't fit for all users involved in the process. This is especially the case for CAD designers who just need to commit their changes without having such a rich graphic interface. To answer this need, we developped a desktop application, interfacing our server with the CAD designer's file system : the DPLM.
First, we developped a command line interface, which is very lightweight and really great for advanced users. However providing a GUI which could interface with the CLI and allow the user to manage multiple files upload at once was more than needed.
Providing a consistent user experience across different platforms has been one of our challenges in the context of our application. The choice of a web framework was then a natural choice. But how could we get it run within a desktop application ? Node-Webkit brought us the ability to interact directly with the user's file system and embed the app in a webview, letting us the choice to use any web framework we wanted to use.
In this talk we will describe our experience developing a reasonably large web application for administrators, consumers and mobile devices using Google's Cloud platform "Google App Engine" and the "Google Web Toolkit" for an AJAX user interface. It will share our decisions made, experiences and learnings in the process and cover areas such as Scalability, Data Storage, Multi-Tenancy, Portability and avoiding platform lock-in, developing for multiple form factors and Bookmarklet development.
Bighead: Airbnb’s End-to-End Machine Learning Platform with Krishna Puttaswa...Databricks
Airbnb has a wide variety of ML problems ranging from models on traditional structured data to models built on unstructured data such as user reviews, messages and listing images. The ability to build, iterate on, and maintain healthy machine learning models is critical to Airbnb’s success. Many ML Platforms cover data collection, feature engineering, training, deploying, productionalization, and monitoring but few, if any, do all of the above seamlessly.
Bighead aims to tie together various open source and in-house projects to remove incidental complexity from ML workflows. Bighead is built on Python and Spark and can be used in modular pieces as each ML problem presents unique challenges. Through standardization of the path to production, training environments and the methods for collecting and transforming data on Spark, each model is reproducible and iterable.
This talk covers the architecture, the problems that each individual component and the overall system aims to solve, and a vision for the future of machine learning infrastructure. It’s widely adapted in Airbnb and we have variety of models running in production. We have seen the overall model development time go down from many months to days on Bighead. We plan to open source Bighead to allow the wider community to benefit from our work.
Building a Pluggable, Cloud-native Event-driven Serverless Architecture - Rea...Dan Farrelly
Building out Reactive systems can be a lot of work. There’s a lot of infrastructure to set up and designing a system to be resilient, responsive, and elastic requires experience and time that not every team has. We built Inngest to be an open source, cloud-native system that enables anyone to build Reactive architectures. Designed to be pluggable with your favorite messaging service like Kafka, NATS or PubSub and your favorite container orchestration like Kubernetes, Nomad, or ECS. We’ll walk through how the system was designed, how you can deploy it yourself, and the plans to make it runnable on any cloud (and even your laptop!).
[WSO2Con Asia 2018] Architecting for Container-native EnvironmentsWSO2
This slide deck explores architectural choices for making applications and integration services first class citizens in a container native environment.
Learn more: https://wso2.com/library/conference/2018/08/wso2con-asia-2018-architecting-for-container-native-environments/
“Node's goal is to provide an easy way to build scalable Network programs”
Asynchronous i/o framework
Core in c++ on top of v8
Rest of it in javascript
Swiss army knife for network Related stuffs
Can handle thousands of Concurrent connections with Minimal overhead (cpu/memory) on a single process
It’s NOT a web framework, and it’s also NOT a language
• Created by Ryan Dahl in 2009
• Development && maintenance sponsored by Joyent
• License MIT
• Last release : 0.10.31
• Based on Google V8 Engine
• +99 000 packages
3. What is Plasma?
● A primary user interface:
● For desktops
● Netbooks
● Smartphones
● Tablets
● Media centers
● A framework:
● For data visualization and editing
● A touch friendly, QGraphicsView based widget library
● Useful to write sandboxed, simple web oriented applications
5. History
● Before Plasma: in KDE 2 and 3
● Window manager: Kwin
●
Desktop: Kdesktop: desop icons, no 3rd party
extensibility
● Panels: Kicker: components such as taskbar are
plugins, simple api, but limited to panels
● Superkaramba: desktop widget system, plugins
written in Python, not compatible with Kicker
7. KDE Workspace 4.0
● Qt4
● QGraphicsView
● Single API: no more 3 incompatible applications
8. Plasma
● Everything is a plugin
● Same widgets can run on panel and desktop:
the concept of formfactors
● Unified framework with strong model/view
emphasis
9. Plasma Desktop
● Even desktop icons become an optional plugin
● You can have multiple “desktop” folders in
different areas -> easy to work on different
projects
● The concept of “activities”: depending on “what
you are doing right now”
● completely different content in the desktop
● Different set of windows shown
● Different behaviour of individual applications
10. Plasma library
● The library that makes this possible has several
components
● Visual: facilities for data visualization, such as a
widget set and the management/layouting of
visual plugins
● Data: fetching and editing of any kind of data
trough plugins with a simple and unified api
11. Visualization
● Plasma::Applet: is a QGraphicsWidget basic visual component: all
visualization plugins inherit from it
● Containment: is an Applet: contains other applets, manages their position,
size, formfactor and lifetime
● Corona: it's a QGraphicsScene: only contaiments are directly inserted into
it, manages the association between containments and Viewports
● View: It's a QGraphicsView, it has an association 1:1 with a Containment,
their geometries are syncronized
● Widget set: set of standard (QGraphics) widgets, from pushbuttons to
flickable views, themed with an SVG engine
12. Data
● DataEngine and DataContainer: all data providing
plugins are instances of DataEngine
● Shared between applets
● A data item will be represented by an unique (in the
DataEngine context) identifier string and will be wrapped
in a DataContainer
● An applet can use more than one dataengine and
mash-up the resulting data
● Service: the way to write data
● If i want to post a twitter update i'll get the service
associated with the source that represents my account
13. Other features
● Package: an Applet can be packaged and distributed
around: it's called plasmoid and is managed by the
Package class, that can install and uninstall them per
user. They should be written with a scripted binding,
preferably Javascript
● Remote applets: A system can export its running
Applets trough the network, the Package will be sent
across o the client machine and the
dataengines/services will run on the sharing one:
● Remote control
14. Netbook: differences
● Not only power and screen size: different use
case from notebooks
● A “desktop” doesn't make sense
● The desktop is an “application”
● No border maximized windows
● Present windows is the taskbar
● Some other different default settings
16. Netbook: Search and launch
● Search more intuitive than browsing categories
● Reuses runners
● Simple menu, no trees
● Use of flicking and drag and drop
18. Netbook: newspaper
● Touchscreen friendly
● Primary place for widgets
● Biggest use case: PIM and webservice client
widgets
19. Plasma Mobile
● Can KDE technologies provided an unified, yet
different experience across diffrent devices?
● Part of the libraries and the look and feel are
preserved
● Here we want a different workspace and
applications UI, while maintaining the logic
behind
20. Challenges
● Smaller physical screen size
● Limited hardware resources
● Different user interaction flow
21. Mobile profiles
● Different slimmed down profiles
● KDE libraries modules become optional
● Solid
● Kioslave
● KnewStuff
● Smaller packages
● Smaller memory footprint
22. Plasma Mobile
● Devices are eterogeneous
● Need for flexibility
● Configuration
● Ease of development
● Test bench for the integration of QtQUICK in
Plasma
23. Plasma Mobile
● Smartphones today: grid of icons, sometimes a
space for “widgets”
● Difficult organization
● Plasma Mobile: “context aware”, who i am,
where i am, what i'm doing
● Set of “activities” like work, messaging, social,
games