FLOSS Project Planets

Tryton News: Tryton Unconference Buenos Aires 2015

Planet Python - Mon, 2015-08-24 08:00

This year the annual Tryton Unconference will take place in Buenos Aires the 13th to 17th November at the Hotel Bauen and gcoop.

This will be the fifth edition and the first one outside the Europe. Users, developers and interested people will have the opportunity to discover or talk about Tryton.

Talk proposals and schedule are managed on Lanyrd.

The third Foundation Supporter Meeting will take place on Saturday 14th, 18.00.

A Sprint is organised at the gcoop place the 15th, 16th and 17th.

Registration is available at TUBA 2015.

If you want to request a talk on a specific topic, you can send your request to the Tryton mailing list. If you have question about the organisation, please contact the foundation at foundation@tryton.org.

And don't forget to spread the word! #TUBA2015

Categories: FLOSS Project Planets

KDE control module usability using the example of KCM for pointing devices

Planet KDE - Mon, 2015-08-24 05:02

After reorganizing the system setting structure, the KDE control modules (KCM) should be updated as well. The pointing device KCM should be the proof-of-concept for all design ideas. Your feedback is highly appreciated, especially in respect to the duality of simple vs. advanced.

Keep on reading: KDE control module usability using the example of KCM for pointing devices

Categories: FLOSS Project Planets

Sooper Drupal Themes: 8 Common Customer Service Complaints All Drupal Developers Will Deal With

Planet Drupal - Mon, 2015-08-24 04:51

Every Drupal developer heard stories of 'clients from hell' and collaborations that turned into nightmares. And, it’s true… you’re going to come across some extremely difficult clients. No matter you do, no matter how hard you work…you’re going to have problems with them. 

Remind yourself: “I am not alone!”

All businesses – no matter what kind of company it is...

Categories: FLOSS Project Planets

Protect your business against cybercrime – train your own hackers

LinuxPlanet - Mon, 2015-08-24 04:40

Cyber criminals have become relentless in their search to find new ways to attack. According to the 2015 internet security threat report by Symantec, last year alone more than 317 million new pieces of malware were created – that’s almost a million rogue software programmes created each day with the purpose of stealing or sabotaging information.

It’s not only large companies that are a prime target, but small and medium businesses too. Cyber crime costs the global economy $445 billion a year and South Africa about R5.8 billion a year. In Norton’s 2013 cyber crime report, South Africa was ranked third worst in the world in terms of its cyber crime threat. And we’re still a very soft target when it comes to cyber crime

 

Businesses need to step step up their game and take a more proactive stance against cyber threats. And that means having people on the inside that think like hackers.

Certified Ethical Hacker training or CEH training is the next line of defence against cyber attacks. It was developed by the International Council of Electronic Commerce Consultants, known as the EC-Council, and is available here in South Africa from technology company Jumping Bean – an approved training centre for the EC-Council. CEH training helps businesses achieve optimal information security by enabling them to scan, test, hack and secure their own systems.

Mark Clarke, Jumping Bean founder, adds, “By training key staff to become ethical hackers they’ll be able to think like hackers. They’ll know what to look out for, what makes your network and applications vulnerable, how to improve them, how to prevent data theft and fraud from taking place, and what countermeasures to take.”

Jumping Bean’s CEH course is offered to site administrators, security officers and professionals, auditors, computer forensic investigators and anyone who is concerned about the integrity of their IT assets and network infrastructure.

The course involves mastering penetration testing, footprinting and reconnaissance (information gathering), and social engineering. Trainees find out how to scan and sniff networks, evade firewalls and IDSs, crack passwords and cover their tracks. They also find out how to hijack Web servers and Web applications, hack wireless networks and create Trojans, backdoors, viruses and worms.

Categories: FLOSS Project Planets

Jan Materne: Managing “My favorite plugins” in Finale

Planet Apache - Mon, 2015-08-24 04:17

Finale is a great notation program. After doing lot of work only by hand I start using plugins. Finale ships a lot of them (and you could purchase more or develop your own …). Now you have many of them, but use only a selection of them on a regular basis.

For easier overview Finale provides a favorite folder. How to get your favorites into that?

All plugins are stored on disk in your FINALE_HOME\Plug-Ins directory. There is also a favorite folder (in German “Bevorzugte Plug-Ins”). All you have to do is copy your required plugin into that folder.

Stop! – copy?

Maybe a copy would break your license (multiple installations), but basically a copy has to drawbacks: increased amount of disk space and hard to update (always update ALL copies).

So use LINKS for that :-)

On windows navigate to your favorite-plugin-directory and create a link using “mklink TARGETNAME SOURCENAME”. For example on my german computer I’ll do

mklink CHKRNG32.FXT "..\Partitur und Arrangement\CHKRNG32.FXT"

for placing the “check range”-plugin.


Categories: FLOSS Project Planets

KnackForge: Clear views cache when insert, update, delete node in Drupal 7

Planet Drupal - Mon, 2015-08-24 00:10

   This blog describes how to clear views cache while inserting, updating and deleting a node. If we want to improve site performance, then views caching is one of the options.

   For example, let's consider that there is a view that display list of records and it will be updated occasionally. Then we can render views data from cache rather than server by setting up cache for views. We can set views cache at Advanced section of its settings page. Drupal supports time based caching by default. We can cache the views until 6 days. If you want to cache the views over 6 days, then you could select 'Custom' option and fill number of seconds in 'Seconds' textbox. 

   Suppose you have cached views for 30 mins. Then it won't display updated data until 30 mins, even if new node is added to that views. It displays updated data only after 30 mins because the views is cached for 30 mins. In that situation, the user can't view new data in cached views. So we need to clear views cache when we add a new node. Then only we can see new data in views and also data is rendered from cache. 

   Lets see how to clear views cache while inserting node:

Categories: FLOSS Project Planets

Python 4 Kids: Python for Kids Book: Project 4

Planet Python - Sun, 2015-08-23 21:44

In these posts I outline the contents of each project in my book Python For Kids For Dummies.  If you have questions or comments about the project listed in the title post them here. Any improvements will also be listed here.

What’s in Project 4

Project 4 introduces the integrated development environment, IDLE, that comes prepackaged with Python. In Project 4 you learn your way around the IDLE Shell and Editor Windows. I demonstrate syntax highlighting, tab completion and editor history (making your coding life easier), how to save a file, open a file and run a file from the Editor window . You also learn how to automatically indent and de-indent your code. This makes working with code blocks much easier!

The coding concepts in this project relate to adding comments to your files – how and where to do it and some tips on adding comments so they are useful in the future. I also show you how to use comments in debugging to skip over “comment out” sections of code.


Categories: FLOSS Project Planets

Python 4 Kids: Python for Kids Book: Project 2

Planet Python - Sun, 2015-08-23 21:36

In these posts I outline the contents of each project in my book Python For Kids For Dummies.  If you have questions or comments about the project listed in the title post them here. Any improvements will also be listed here.

What’s in Project 2

Project 2 is a Hello World project that covers some important basics, including what literals are, how you name a literal in order to store it (ie variables). It shows the different ways to make a string literal.If you’re going to name a value you need to know about Python’s naming rules (and PEP8 naming conventions – yah but I don’t actually mention PEP8). Those naming rules themselves rely on you not using a keyword as a name, so you also get a list of Python keywords in this project.

It also covers Python’s print statement, looping with while (including the notion of a conditional and a code block). looping with for and counting with range. By the end of the Project you can fill the screen with “Hello World!”.  To do so you repeat something 300 times. I introduce the concept of magic numbers and explain why they should be avoided. I offer the use of variables in ALL_CAPS to use as constants.


Categories: FLOSS Project Planets

Python 4 Kids: Python for Kids Book: Project 3

Planet Python - Sun, 2015-08-23 21:35

In these posts I outline the contents of each project in my book Python For Kids For Dummies.  If you have questions or comments about the project listed in the title post them here. Any improvements will also be listed here.

What’s in Project 3

Project 3 explores a guessing game from the command line. In order to get a guessing game up and running you need to know how to receive input from the user. This project introduces the raw_input() builtin to accommodate this.

In order to tell whether a guess is correct, the computer must compare the guess to an answer – using the == operator. Further, since raw_input returns a string, I explain that strings and numbers are different and introduce the int() builtin in order to be able to compare the input with a number.

To give a player feedback, you need to determine whether the guess was higher or lower than the desired number. The operators > and < are introduced to address this. The if conditional along with the variants elif and else are introduced to be able to structure the feedback given to a player.

To choose a number at random you learn about import, the random module and random.randint.

The while structure introduced in Project 2 is used to allow the player to make repeated guesses of the answer. This is coupled with the break keyword to exit the loop one the correct number is guessed.

In the course of introducing the ==, > and < operators, I also give an overview of more common operators used in Python (at Table 3-1).  After introducing the operators I discuss why division in Python is a special case, how to recognize problems with division and how to get a decimal answer if that’s what you’re after.


Categories: FLOSS Project Planets

Bryan Pendleton: I spent the whole weekend reading!

Planet Apache - Sun, 2015-08-23 21:21

Actually, that's not true. I went to the beach with the cousins on Saturday afternoon.

  • Lessons Learned From Reading Post MortemsOne of the things I find to be curious about these failure modes is that when I talked about what I found with other folks, at least one person told me that each process issue I found was obvious. But these “obvious” things still cause a lot of failures. In one case, someone told me that what I was telling them was obvious at pretty much the same time their company was having a global outage of a multi-billion dollar service, caused by the exact thing we were talking about. Just because something is obvious doesn’t mean it’s being done.
  • How does a relational database workIn this simple example, I end up with many possibilities. But a real query can have other relational operators like OUTER JOIN, CROSS JOIN, GROUP BY, ORDER BY, PROJECTION, UNION, INTERSECT, DISTINCT … which means even more possibilities.

    So, how a database does it?

    Dynamic programming, greedy algorithm and heuristic

    A relational database tries the multiple approaches I’ve just said. The real job of an optimizer is to find a good solution on a limited amount of time.

    Most of the time an optimizer doesn’t find the best solution but a “good” one.

    For small queries, doing a brute force approach is possible. But there is a way to avoid unnecessary computations so that even medium queries can use the brute force approach. This is called dynamic programming.

  • bcachefs - a general purpose COW filesystem For those who haven't kept up with bcache, the bcache codebase has been evolving/metastasizing into a full blown, general purpose posix filesystem - a modern COW filesystem with checksumming, compression, multiple devices, caching, and eventually snapshots and all kinds of other nifty features.
  • The Programmer's Guide to bcacheAt a high level, bcache's btree is a copy on write b+ tree. The main difference between bcache's b+ tree and others is the nodes are very large (256k is typical) and log structured. Like other COW b+ trees, updating a node may require recursively rewriting every node up to the root; however, most updates (to both leaf nodes and interior nodes) can be done with only an append, until we've written to the full amount of space we originally reserved for the node.
  • Cake Technical InformationCake instead schedules packets based on time deficits. If no deficit exists when a packet is requested, it can be sent immediately. The transmit time of the following packet is then calculated, and until that time the shaper is placed in deficit mode. While in deficit mode, packets are scheduled using a watchdog timer whenever a request arrives too soon, and transmission times are calculated for a continuous packet train. This continues until the queue drains; if a packet is requested, but none are available and the next transmission time has been reached, the shaper returns to the quiescent state in which the next packet can be sent immediately.

    Deficit mode makes the burst size dependent only on hardware and kernel latency (including timer resolution), and minimises bursts without requiring manual tuning. Cake's shaper can therefore be set much closer to the actual link speed without jeopardising latency performance. Modern hardware can achieve sub-millisecond bursts in most cases.

  • The impact of fast networks on graph analytics, part 1tl;dr: A recent NSDI paper argued that data analytics stacks don’t get much faster at tasks like PageRank when given better networking, but this is likely just a property of the stack they evaluated (Spark and GraphX) rather than generally true. A different framework (timely dataflow) goes 6x faster than GraphX on a 1G network, which improves by 3x to 15-17x faster than GraphX on a 10G network.
  • Multi-million operations per second on a single Google Compute Engine instanceOften times technology vendors advertise scale-out as a way to achieve high performance. It is a proven approach, but it is often used to mask single node inefficiencies. Without a well balanced system where CPU, memory, network, and local storage are properly balanced, this is simply what we call “throwing hardware at the problem”. Hardware that, virtual or not, customers pay for.

    To demonstrate this, we decided to check Helium’s performance on a single node on Google Cloud Platform with a workload similar to the one previously used to showcase Aerospike and Cassandra (200 byte objects and 100 million operations). With Cassandra, the data store contained 3 billion indices.

  • The most timeless songs, measured using play counts on SpotifyUntil recently, it was impossible to measure the popularity of older music. Billboard charts and album sales only tell us about a song’s popularity at the time of its release.

    But now we have Spotify, a buffet of all of music, new and old. Tracks with fewer plays are fading into obscurity. And those with more plays are remaining in the cultural ether.

  • Designing And Building Stockfighter, Our Programming GameWhy? Well, a lot of the fun engineering problems in trading are caused by it actually not being reliably the case that you send in an order and it gets unproblematically matched at “the price.” Markets are distributed systems. The exchange’s view of reality and your trading system’s view of reality are, by necessity, separated by the great firewall known as “physics.” For maximum possible results, you have to be able to do things like accurately predict what the future state of the exchange is, because the order you’re composing right now will arrive in the future not the present, while being cognizant that your present view of the exchange’s state is actually the exchange’s past.
Categories: FLOSS Project Planets

Davide Moro: Kotti CMS - frontend decoupled from backend. How we did it (part 2)

Planet Python - Sun, 2015-08-23 20:05

In the previous article http://davidemoro.blogspot.it/2015/07/kotti-cms-successful-story-part-1.html we have seen that:
  • decoupled public website from the private content management is cool
  • Python and Pyramid is cool
  • don't use PHP please :)
No we will see:
  • how to build a pure Python Kotti based setup with a private content management area decoupled from the public website (with tips, links, technical details and screenshots)
Here you can see some screenshots, implementation details and links.
Project setupThe installation folder is a package that contains all the application-specific settings, database configuration, which packages your project will need and where they lives.

From https://pypi.python.org/pypi/mr.developer.The installation folder is a "one command install" meta package:
  • replicable
  • under version control + git flow
  • documented + change list for each plugin and the project itself
  • with a tag based deploy
  • based on Python pip/requirements.txt
  • batteries included
  • exceptions logging on file (with logrotate) enabled by default
  • automated deploy
so let the computer works for us and have fun.
See:
PopulatorsPopulators are functions with no arguments that get called on system startup, they may then make automatic changes to the database like content initialization.

Populators are very important because when you install the project folder during development or on the very first production instance you'll find all the most important contents and sections by default. Things will be created automatically if the database is empty, so you don't obtain a blank site on the very first install.

Populators are also good for improving the first impact of the end users (I mean editors) with the platform because they see all the main sections already there.

See:
Private backend areaTurning Kotti CMS into a private content administration is quite easy:
Later I've created a generic package that does all the things for you (kotti_backend):
so things are even easier now (install kotti_backend, done).
Multilingualkotti_multilingual is your friend.

Goto frontend link, translation management and link to the technical documentation online based on SphinxSee:
Elastic searchkotti_es provides ElasticSearch integration for fulltext search. This plugin needs more love and and a complete refactor (it was built in a hurry and I'm not yet satisfied) but it proved there are no known issue after months of intensive usage.
Probably things will change, hope other guys with the same needs will contribute.

See:
Main navigation and header/footer linksYou can use the kotti_actions plugin if you want to implement footer, header links or even nested main navigation menus. Obviously kotti_actions is ment to be used with a decoupled frontend.

As you can see a custom colour can be assigned to courses, navigation links, sections and every kind of object thanks to the json annotations column provided by default by Kotti. So you can add arbitrary fields.

How the multilevel menu looks like on the public websiteSee:
Portlets The main layout based on box managers for portletsThe kotti_boxes is your friend. This plugin is ment to be used with a decoupled frontend. And it was quite quick implementing portlets because we didn't need to customize the private backend area.

You can define different page layouts for each resource type (home page, news, courses, etc) and show boxes in well defined areas (box managers), for example LeftBoxManager, AboveFooterBoxManager and so on.

So box and box managers are just non publishable contents and you can:
Banner portlets with links
  • copy/paste them
  • assign workflow with different security policies to box and box managers
  • assign different views
  • share edit permission to certain box or box managers to particular users or groups
  • prevent certain type of boxes to be included in some areas (for example: banner box image only addable to the left box manager).
See:
Editor toolbarAs you can see if you are logged in the frontend will show an editor toolbar with:
  • link to the backend version of the page
  • object information (state, type of object, etc)
Info and links to the backend, edit and folder contents
or see exactly the website as an anonymous user (very common customer request):

Anonymous viewYou can also add more features, for example direct edit links for images or portlets or live edit features.

Talking about a pure Python solution, you might implement this feature with a Pyramid Tween (I hope I'll have enough spare time to do that. Anyone would want to contribute? We are very welcome, contact me!):
Course types (custom content types)The course view with portlets and collapsable paragraphsThey are a sort of rich documents with an image attachment column and integrated with an external ecommerce site. When you add a course type there is an event that initializes automatically subobjects and the main image attachement by default, so less work for editors.

In addition all image content types and image attachments are addable or editable just by allowed users thank to custom roles and global or local permission sharing.

Collapsable paragraphs are implemented with custom content types not directly reachable on the frontend.

There are a lot of fields on this content type, so they are grouped together using fieldsets.
Editors can also create a base private course model and then copy and paste it when new courses should be added.

Sometimes you want to prevent the addability on the site root for particular object types, this way things will remain always tidy (why you should add a course on the very root of the site?).

See:
Windows and MySQL issues and tipsKotti can be installed on Windows but I strongly suggest to adopt a Unix-like server with Postgresql instead of MySQLas storage layer: 
TestsAll the software is tested. Very happy with the py.test framework.

See:
Other third party Kotti pluginsI've used the following third party plugins that can be used on a standard Kotti environment:
See also the full list of available plugins:
Photoes and creditsAll the screenshots shown in this article are taken from the "MIP Politecnico di Milano's graduate school of business" website:
So the MIP's website backend is powered by Pylons/Pyramid and Kotti CMS, I'll write a non-technical case study soon. In the mean time many thanks to:
  • MIP
    • Simona Strepparola, Head of Communication
    • Gabriele Bedani, Microsoft Sysadmin
    • all the MIP staff
  • Truelab 
    • Riccardo Bonini, project manager
    • Ruben Barilani, web developer
    • Caio Ceccon, web developer (Faculty and Staff implementation). Python developer that joined us for only 5 days but enough to become good friends! He never touched a Pyramid/Pylons or Kotti application but he was able to be productive in a couple of days, this proves the Pyramid/Pylons developer friendliness
    • Davide Moro, it's me
    • Andrea Sironi, creative director
Results You can consider Kotti as a very good, secure, flexible, battle tested and easy to approach solution for important customers.
All Kotti posts published by @davidemoro
Next steps Reading this article you should find all the bricks you need if you want to implement a public website decoupled from its backend with Kotti.

Now I'm assembling the above bricks in order to provide an "easy to install" solution with the same pattern I've described here. This is my roadmap:
It can be considered a good starting point for:
  • CMS-ish application
  • a generic framework for building generic web apps or single page web applications (remember, Kotti is not only a CMS, it could be considered as a framework)
So stay tuned and if you like this work please consider to contribute with
  • code
  • testing
  • issue reporting
  • Github stars
  • spreading the word 
or why not sponsorships!

And if you want to know more about Kotti and you are attending +EuroPython Conference 2015 in Bilbao don't miss the Andreas Kaiser's talk "Standing on the Shoulders of Giants: The Kotti Web Application Framework". I'll join the sprint (remotely) at the end of EuroPython so see you on IRC (http://webchat.freenode.net/?channels=kotti). If you want to stay tuned follow https://twitter.com/KottiCMS.
Categories: FLOSS Project Planets

Davide Moro: Introducing substancek. A Kotti project

Planet Python - Sun, 2015-08-23 20:03
Let me introduce substancek, a Kotti (http://kotti.pylonsproject.org) project.
What it is substancek?substancek is:
  • Kotti (web application framework) + decoupled admin interface
It is only an additional layer upon the following opinionated stack:
with the following motto:
"""(even) better development experience and complete frontend freedom"""and introduces (or better promotes) the concept of private admin area (backend) decoupled from the public side (frontend) of your web applications built with Kotti.

In other words it is a set of technologies addressed under the substancek brand that let you extend Kotti in order to use it just as a private backend administration area for your application data.

So you are still using plain Kotti with an additional package (at least kotti_backend depending on what you need).

If you want to know more I've discussed here benefits and why frontend decoupled from the backend pattern. See http://davidemoro.blogspot.it/2015/07/kotti-cms-successful-story-part-1.html
      substancek nameTribute to:
      • substanced (http://www.substanced.net). Carefully designed, well documented Python web development framework based on Pyramid/ZODB. It shares the concept of management views decoupled from the retail views for each published resource
      • kotti (http://kotti.pylonsproject.org). The Kotti framework
      When substancek is for youAny project of any size (from micro to XXL) involving content management that needs:
      • RDBMS. Kotti is an opinionated framework opposed to plain Pyramid. The persistence layer is managed by SQLAlchemy (http://www.sqlalchemy.org)
      • user friendly and production ready admin/editing interface for content producers so they can immediately start adding content to your web application with copy/cut & paste, clean urls, etc
      • rapid development. Pyramid and Kotti are easy to learn and let you become productive quickly and speed up your development. Even more with the decoupled admin interface.
      • stability. Pyramid and Kotti exist since many years and they are solid rock solutions production ready
      • frontend freedom. The admin interface comes for free while it is completely up to you add what your application needs (retail views). Since they are completely two different applications there are no css/js conflicts and you can integrate your preferred frontend tool chain without get influenced by how the admin interface is built.
      • flexibility. Pyramid won't hold you back when your application is small and won't get in your way when your application becomes large.
        Even if you start small, using Pyramid you anticipate what customers will need later avoiding expensive rewrites and this can make the difference. In other words this also means successful projects in the long term. Same for Kotti. See What makes Pyramid unique.
      So if you project needs (or in future iterations) one or more:
      • complex security policies
      • workflows
      • hierarchical data support
      • or even intranet/extranet like collaboration areas
      you might consider even more substancek (kotti_backend + Kotti + Pyramid + SQLAlchemy).

      For example:
      • very small applications. For example a just one view public json endpoint for published news-like resources consumed by a third party app with an admin interface for editing contents
      • heavy Javascript based applications with modern frontend tools (eg: SPA + REST) with a decoupled admin interface
      • content management solutions
        • blog
        • ecommerce
        • intranets
        • large CMS-ish applications
      Note well: if you don't need workflows don't be scared because there is no overkill. You can use a one state workflow or no workflow at all for example. No hierarchical data? Use not nestable resources and so on. If it comes out later that you need them it will be quite easy converting your code.
      AlternativesYou can use plain Kotti, without the substancek's kotti_backend setup. Or if you prefer noSQL try the excellent substanced (substanced + Pyramid + ZODB). Both solutions are lightweight, tested, well documented and easy to learn. Alternatively if you need really a minimal and unopinionated solution you might use plain Pyramid.

      Do you need something more? You might consider to use Plone (https://plone.org) as a framework.

      Anyway the good news is that Python is plenty of good options.
      substancek architecture detailsAs already told you the private admin area (backend) and the rest of the application (frontend) are two complete different applications with different settings, different views and shared authentication.

      Assuming you are going to use PasteDeploy to run your application, let's consider the following configuration files setup:
      • backend-dev.ini, configures the private admin interface based on Kotti thanks to the kotti_backend plugin
      • frontend-dev.ini, configures your application you are developing (a full CMS frontend implementation or a microapp with just one retail view).
      • development.ini (optional), mount the backend-dev.ini and frontend-dev.ini applications in the same process (/admin for the private admin interface and / for your application). Alternatively you can run the frontend and backend using two processes waiting for requests on different ports and play with rewrite rules.
      backend-dev.ini[app:kotti]
      use = egg:kotti

      ...
      pyramid.includes =
      pyramid_debugtoolbar
      pyramid_tm
      kotti_backend.views.override_root_view


      kotti.configurators = kotti_tinymce.kotti_configure
      kotti_backend.kotti_configure

      kotti.use_workflow = kotti_backend:workflows/simple_backend.zcml

      kotti_backend.goto_frontend = 1 This is a normal Kotti setup with:
      • enabled the (optional) root view override for our admin interface. In other words the default root view will be @@contents instead of the standard Kotti's hello page (see pyramid.includes)
      • added kotti_backend to kotti.configurators
      • override the Kotti's default workflow with the one provided by kotti_backend (kotti.use_workflow). Playing with the additional pview permission you can decide your resources visibility on the frontend. See the workflow definition here https://github.com/Kotti/kotti_backend/blob/master/kotti_backend/workflows/simple_backend.zcml
      • enable a "Goto frontend" link (kotti_backend.goto_frontend) for easy switching from admin interface and frontend 
      See more options on the kotti_backend's README file:
      frontend-dev.ini[app:main]
      use = egg:Kotti
      ...

      kotti.use_workflow = kotti_backend:workflows/simple_backend.zcml

      kotti.configurators =
      your_package.kotti_configure

      kotti.base_includes =
      kotti
      kotti.views
      On the frontend configuration file we share the same workflow in use on the admin interface (kotti.use_workflow).

      One of the most important configuration is the kotti.base_includes override: here we decide what will be loaded on our application. We omit all the Kotti views loaded by default in the standard setup and we load what we want to include where:
      • kotti, loads the kotti "core"
      • kotti.views (optional), load some view discriminators and utils defined by Kotti if you need them
      • your_plugin.your_includes, load your includes registering the views needed by your application
      The kotti.configurators typically auto includes your package and tell what should be included in your application (pyramid.includes). See the Kotti documentation for more info.

      In other words:
      "what is not loaded, it doesn't exist"so the final result is that there is nothing exposed on the frontend except what you decide to load and extreme control. You can register just only one view application or configure a complex setup for a CMS-like application: it's up to you registering only the views your application needs and no more. This way you can use completely different frontend frameworks, different versions of Javascript libraries, you have no css/js conflicts and no need to hide unneeded things and you decide which resources will be published on the frontend.

      See also another advance usage pattern "Using Kotti as a library" http://kotti.readthedocs.org/en/latest/developing/advanced/as-a-library.html
      development.ini# See http://pythonpaste.org/deploy/#paste-composite-factory
      [composite:main]
      use = egg:Paste#urlmap
      / = config:frontend-dev.ini
      /admin = config:backend-dev.ini


      [server:main]
      use = egg:waitress#main
      host = 127.0.0.1
      port = 5000The (optional) development.ini shows how to configure a composite application with different mount points. You can change /admin with /cms or /whateveryouwant depending on your needs.
      Examples You can checkout the https://github.com/substancek/substancek_cms_theme package if you want to see in action a (quite complex) example.

      I'm going to provide more and simpler examples (eg: a pretend micro application), see the roadmap.
      What are the substancek related packagesHere you can see the whole substancek ecosystem:
      • kotti_backend, generic package that turns Kotti to a private admin area. This is the keystone for every substancek like project
      • CMS-like applications
        • substancek_cms (roadmap), a Kotti CMS distribution with an alternative frontend theme based on SASS, html/templates minification and assets optimization based on Yeoman tools. It will be based on the kotti_project experiment available here https://github.com/davidemoro/kotti_project
        • substancek_cms_theme, an example public side CMS implementation based on Kotti built with SASS and html/templates minification
        • kotti_actions, link actions backend implementation for header, footer and main navigation links
        • kotti_boxes, portlets and box backend implementation
        • kotti_es, elastic search support (to be refactored)
      • common utilities
        • pyramid_html_minifier, generic Pyramid package that introduces Chameleon templates minification with no overhead. Required by substancek_cms_theme.
        • build_commands, generic Python package that defines a set of initialization commands on install (eg: python setup.py npm/bower/gulp) for frontend stuff. Required by substancek_cms_theme.
      Who's using substancek technologiesMIP - graduate school of businessThe MIP (Politecnico di Milano graduate school of business - www.mip.polimi.it/en) uses substancek technology inside for the private admin interface. This approach is so flexible that let you use Kotti as a private admin content management area and even implement your public views using other frameworks or non Python languages (for example PHP+Symfony2).

      See:
      substancek_cms_themeThis is a work in progress opinionated CMS frontend implementation that reuses existing Kotti templates and logics.

      The look and feel is the same you get with a standard Kotti installation but it shows how to integrate and distribute a Python package integrated with a Yeoman setup (http://yeoman.io) that provides:
      • production vs development setup. In production mode will be used assets and templates from the dist
      • Chameleon templates minification with no overhead thanks to pyramid_html_minifier when you are in "production" mode
      • SASS
      • image/assets optimization
      • build commands for npm/bower/gulp initialization thanks to the generic package build_commands
      Once installed you'll see the admin interface visiting http://localhost:5000/cms.
      See the code here: https://github.com/substancek/substancek_cms_theme
      Next stepsIf you want to contribute there is a lot to do:
      • contributions to the Kotti core (for example @@contents pagination, REST, etc and new ideas)
      • creation of the substancek_cms package that puts together the substancek_cms_theme default theme plus the most useful third party Kotti plugins like news, events, etc with decoupled admin interface and Vagrant/Ansible automated setup based on kotti_project for easy installation/evaluation
      • creation of simple pretend packages, add more examples (microapp, blog)
      • a toolbar available on the frontend just of editor users for improved usability (the same shown in the MIP case history) implemented with a Pyramid tween
      • more work on substancek_cms_theme, implement advanced features shown in the MIP case history like link managers and portlets and refactor the Yeoman folder removing what is not strictly needed
      • scaffolding, help people create new projects with decoupled admin interface using Kotti as a framework
      • substancek dedicated github page
      Contributions, feedback or pings like "hey, I'm going to use Pyramid/Kotti for the my next project" will be very appreciated!
      DocumentationAll Kotti posts published by @davidemoro
      Twitter links
      Categories: FLOSS Project Planets

      Advanced Metadata Hub implemented

      Planet KDE - Sun, 2015-08-23 20:00

      One and a half months passed since the mid-term evaluation and now is the time to write down about final result. I was somehow surprised that I managed to finish everything on time (just one day after the firm pencils down date, so almost on time). The reason of me always being late with implementation is the amount of unexpected complications that my appear while I implement mu project.

      Since my project is done lets take a quick overview of new features that digiKam will include starting from next 5.0.0 release. The first one: More user control over metadata namespaces and how digiKam handles read and write. Compared to mid-term screenshot, the settings menu responsible for managing namespaces is fully functional and was redesigned to be more intuitive and easier to use. Also, more tips were added and button icons are in place.

      It allows full control over existing namespaces, such as adding, deleting, reordering and disabling namespaces. Because it is such a low level functionality, we had to enforce restrictions on what can be done in this menu, to avoid unexpected results.

      First, we have a number of default namespaces which digiKam was using before. Default namespaces can’t be deleted or edited. They can only be disabled. These entries are essential for digiKam, so I decided that users might delete it by accident and then will be very hard to recover without a reset to default. Some namespaces hold special parameters designed for particular cases, so editing them is a bad idea, hence, the disabled edit.

      The most powerfull part of this menu comes from reordering and disabling namespaces. The order is important for reading tags, rating and namespaces. digiKam will search for tags, comments and rating in given namespaces and return the first non-empty result. If you know that you have images tagged with a different program, you will like to prioritize that namespace.

      The second powerfull option is disable. The list of namespaces is quite big, for greater compatibility. If you don’t need them all, disable the ones you don’t use, so metadata will be easier to read.

      Another important option comes with unified read and write. If this option is checked, both read and write methods for seting and geting tags,rating, comments will use the same list. Previously this information was written for each method and some patches forget to fix both read and write. The result, you delete metadata and it keeps reappearing.

      This concludes namespace changes operated on digiKam. Now it is the time for the second part of the project: Lazy Metadata Syncronization

      Before, digiKam was syncronizing metadata when you just applied a tag, rating or comment to an image. Since some people use slow hard-drives, or collection is somewhere on NAS, writting metadata is a long process even for few files. Users were experiencing constant slow-downs.

      With the new approach, we apply changes to database and keep a list of files to be syncronized later.

      As you can see from screenshot, when you enable lazy syncronization in the menu, a new status item will apear, which will inform you that there are no pending images for syncronization.

      After you applied tags, ratings and comments, the status bar will inform you that there is a number of images which await syncronization. To apply changes, you can use the button on the status bar. Also, when digiKam closes, changes are applied automatically.

      This concludes my list of changes. Hope you will find my improvements useful. Use digiKam and have fun!

      Categories: FLOSS Project Planets

      Centimeters and Points are the best

      Planet KDE - Sun, 2015-08-23 20:00

      What is the best unit? Of course there is no best unit. But for some purposes some units are better than others.

      In digital documents, there is often a choice of units with which to specify absolute lengths. CSS, SVG and ODF have a choice of inches (in), centimeters (cm), millimeters (mm), picas (pc), points (pt) and pixels (px). Editing files with different computer programs or different versions of programs can lead to mixed use of units.

      For example, when saving ODF with LibreOffice, the unit that is used for storage depends on the user preferences. This can lead to inconveniences and rounding errors. If I specify a margin of 1.25cm and send it to someone who has the preferences set to use inches, the margin will be stored as 0.4925in. When that number is converted back to centimeters, the value is 1.25095cm which is 1‰ more than the original value.

      In addition to the loss of precision, consider the user interface. That shows a weird value now: 1.25095cm. The lengths in office documents are usually not measurements; they are nice numbers chosen by users. Most people choose lengths to be round numbers in the particular unit they are currently working with. 0.3175cm and 9pt are exactly the same length, but only one representation is likely to be the one that was chosen by a user.

      These conversion problems can be avoided by decoupling the units used in the user interface from the units used when saving.

      Lossless conversion

      Here is a small table with the exact multiplication factors for conversion between the length units:

      in cm mm pc pt px in 1 2.54 25.4 12 72 96 cm 50/127 1 10 600/127 3600/127 4800/127 mm 5/127 0.1 1 60/127 360/127 480/127 pc 0.25/3 0.635/3 6.35/3 1 6 8 pt 0.125/9 0.3175/9 3.175/9 0.5/3 1 4/3 px 0.03125/3 0.079375/3 0.79375/3 0.125 0.75 1

      The green multiplication factors give lossless conversion. The red multiplication factors give lossy conversion for decimals. Let's look at the conversion between inches and centimeters again. Conversion from inches to centimeters is lossless. The conversion with 2.54 will add two extra digits, but the resulting value can be written in decimal representation and is always exactly the same length.

      Conversion in the other direction, from centimeters to inches, is problematic. The centimeter value is divided by 127, which leads to an infinite sequence of digits for most values.

      The column for conversion to inches is almost entirely red: writing a length out in inches nearly always leads to a lossy conversion.

      There is no single unit that can save any length losslessly. But a combination of cm and pt does cover all cases. Any length can be written out without loss of precision by using either cm or pt.

      Normalization

      Recently, I've developed an urge to normalize ODF files. ODF, expecially in the flat file format (a single XML file), is convenient for writing texts that are stored in version control systems. It's like plain text but with added features like bold, italic, named styles, tables and mathmatical formulas. ODF is also the best file format you can hope to get from a non-programmer.

      Programmers like to put files in revision control systems and look at diffs between different versions of a file. This is where normalization is needed. Office applications are really complex and each one has its own peculiarities in saving files. These peculiarities have no influence on the semantics of the documents but can make a diff between two versions larger than needed.

      The solution is to remove the peculiarities. This process is called normalization. Normalization is hard to perfect, but even imperfect normalzation is helpful.

      One step in normalization is to standardize on the unit that is use for lengths. The conversion should be lossless. The unit that is used carries no meaning in ODF, but the length itself should be transferred exactly. For normalizing lengths in ODF I'm currently using the following logic: if a length can be converted losslessly to centimeters, do so, if not, then use points. In this way, two documents with different origins will have stored equal lengths as equal character sequences.

      Categories: FLOSS Project Planets

      Justin Mason: Links for 2015-08-23

      Planet Apache - Sun, 2015-08-23 19:58
      Categories: FLOSS Project Planets

      PreviousNext: Boosting performance of a complex Drupal 7 project with Blackfire.io

      Planet Drupal - Sun, 2015-08-23 19:49

      Earlier in the year we worked with a household Australian name to help them build a next-generation more-performant version of their energy-comparison site.

      We used Blackfire.io to optimize the critical elements of the site.

      Read on to find out more about our experience.

      Categories: FLOSS Project Planets

      Norbert Preining: Debian/TeX Live complete update

      Planet Debian - Sun, 2015-08-23 18:50

      Triggered by all the bugs around font problems I spent my weekend instead of mountaineering with crawling through the TeX Live history for changes and fixes to dvipdfm-x. Thanks to 角藤さん for his hints, I have pulled out the changes necessary to fix Type1 support in dvipdfm-x and have reincluded them into the Debian texlive-bin package. The uploaded binaries (version 2015.20150524.37493-6) are already compiled against the new C++ ABI, see the Debian transition, so most systems will still need to wait for the update to be installable.

      At the same time I did an update to the whole set of arch: all packages (texlive-base, texlive-lang, texlive-extra (version 2015.20150823-1). This was triggered by bug that seems to be caused by bad interplay between fontspec and l3 packages. Furthermore, I needed to remove the activation for fontconfig of the URW++ Base35 fonts, to ensure that fontconfig returns always the ones from the gsfonts package, instead of a mixture between TeX Live and gsfonts.

      Unrelated bug fix: libpaper intergration has been fixed and should work again. So for now all the bugs are now hopefully settled and we are back to normal. What remains is trying to fix jessie which is also broken in some respects.

      Updated packages

      acro, animate, babel-bosnian, babel-french, babel-latin, beamer-FUBerlin, beebe, breqn, chemformula, chet, cnltx, crossrefware, dantelogo, datetime2-it-fulltext, disser, drm, dvipdfmx-def, ecclesiastic, eledform, gradstudentresume, idxcmds, l3build, mcf2graph, media9, pageslts, pdfpages, reledmac, siunitx, tcolorbox, tex4ht, texlive-docindex, texlive-scripts, udesoftec, upmethodology, xindy.

      New packages

      blochsphere, e-french, fitbox, nar

      Enjoy.

      Categories: FLOSS Project Planets

      Freedreno on Android: Current Status

      LinuxPlanet - Sun, 2015-08-23 16:24
      Freedreno now supports dma-buf passing instead of GEM flinks on kitkat-x86, but with a catch. Enabling freedreno’s userspace bo cache in libdrm (bo_reuse=1) results in multiple GEM_SUBMIT calls on the same bo, and the GPU hangchecks after some activity. HACK: setting bo_reuse=0 runs Android smoothly.

      While fighting some userspace GEM leaks that showed up with bo cache disabled, I started looking into adding a minigbm (used by chrome-os) backend for msm. The idea was to let GBM deal with hardware specifics and leave gralloc platform independent. Another priority was doing away with GEM names to bring in fd passing. With bo_reuse=1, fd_bo_del() calls would segfault during fd_cache_cleanup(), causing SurfaceFlinger to restart.

      After watching `/sys/kernel/debug/dri/0/gem`,counting allocs and frees and scratching my head for a while, I discovered that the GEM leaks lay in AOSP’s default Home launcher, and moving to CyanogenMod’s Trebuchet launcher made the leaks go away.

      Making gralloc_drm switch to dma-buf fd’s, I also got to learn how Mesa’s EGL implementation works, and wrote a couple patches ([1] and [2]) to implement __DRI_IMAGE_LOADER DRI extension that helps EGL allocate textures without dealing in flink names. These let a __DRIimage be tied to ANativeWindowBuffer and used for textures.

      One possible reason with fd_cache_cleanup() segfault, assumingly, was using an old (3.19) kernel that was missing some related fix, so we decided to switch to 4.2 instead. I had to make some changes to resurrect the android logger driver since it was deprecated after Kitkat + 3.19. I learned of kernel’s Asynchronous IO support, and forward ported logger to be compatible with the kiocb API changes.This didn’t help the segfault, but fixed a screen flicker issue on the sides.

      I traced the bo life-cycles through drm_{prime,gem}.c and libdrm, and finally found the problem – importing a bo present in the cache would break the cache bucket, causing any following bo_del()s to crash. The fix turned out to be simple to write, but difficult to point out.

      It’s been an incredible learning experience where I got to explore a great number of modules up close, that come together to interact and form the display subsystem. I’m excited to stick around, improve support and dig up more items to work on. Thanks Rob, Emil, #freedreno, #android-x86 and #linaro for all the support!

      Up next:
      I’m looking into the `*ERROR* handle X at index Y already on submit list` + hangchecks that pop up with bo_reuse=1. Also need figure out how to get some games running (dexopt won’t let me install .apks : ( ).


      Categories: FLOSS Project Planets

      Doug Hellmann: virtualenvwrapper 4.7.0

      Planet Python - Sun, 2015-08-23 12:03
      This release improves MSYS support for 64bit systems. What is virtualenvwrapper? virtualenvwrapper is a set of extensions to virtualenv. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies. What’s … Continue reading virtualenvwrapper 4.7.0
      Categories: FLOSS Project Planets

      Mark Koester: Using Rules to Periodically Change a Your Drupal Site Configuration and Variables

      Planet Drupal - Sun, 2015-08-23 09:45

      Wouldn’t it be cool if you could use Rules to periodically set, change or modify certain Drupal site configurations and variables?

      Yeah, it would be cool and nowit is totally do-able with "Rules Set Site Variables”

      Below is my use case and a simple recipe on how to use Rules (and a few helper modules) to change site configurations periodically. I imagine you can use it for all kinds of other craziness on your Drupal site.

      Use Case: Modifying Node.Js Host Configuration Variable on Schedule

      We are huge fans of Drupal and Node.js and use it on multiple integration projects. Combined together, Drupal provides powerful information handling and Node.js handles real-time scalability.

      We use Heroku to handle our free, node.js Chatroom Demo site. Unfortunately, Heroku is ending its policy of forever free dyno and moving towards a limited free usage of 18 hours per day. It’s an understandable, business change. For our free Drupal, Node.js chatroom demo, this means I’d need to pay $7 per month to keep the site up and show the [amazingness of Drupal and Node.js](http://int3c.com/tags/nodejs OR shut down the site.

      So, instead of paying this (I’m cheap), I decided to setup two Heroku, Node.js instances and simply use a Drupal cron process to flip my node.js server twice a day.

      The end result is that twice a day my Drupal site will change which node.js server it is using and thus prevent me from overusing my free, 18 hour daily limit.

      Technically, I could have written some custom code, but being a lazy Drupal developer and site builder, I figured there had to be some way to do this with Rules.

      Unfortunately there wasn’t at the time. The only similar solution was Conditional Variables, which would only set a session variable and not a permanent change to the configuration.

      My solution was to create "Rules Set Site Variables”, which provides a custom reaction where you set any Drupal site variable. You can read more about that module in "Announcing: Rules Set Site Variables Module.”

      In order to solve my use case to switch Heroku Node.js server, the final solution involved using Rules, Rules Once Per Day and "Rules Set Site Variables” as well as a couple of site and rules configurations.

      Let’s take a look at how.

      Which Modules? Rules, Rules Once Per Day and Rules Set Site Variables

      In order to accomplish this task of periodically changing a site configuration, I used three modules (besides whatever else I’m using for Node.js and other parts):

      I could have used a different triggering method but Rules Once Per Day was the easiest. Rules Once Per Day creates a Drupal event, which you can control and set to a specific time and which you can use as the triggering event with Rules.

      Using "Rules Set Site Variables”, you then have the option of creating a Rules Reaction to set a Drupal variable.

      After enabling these modules, there were only a few simple configurations.

      Cron and Rules Once Per Day

      In order for this to work you are going to need a functioning cron task on your server. This article won’t go into how to configure cron. But essentially for this to work, your server needs to run cron periodically in order to trigger rules and other things. In general you want cron to run every few minutes.

      Rules Once Per Day provides a simple configuration setting page where you can configure when you want it to run according to your site time. This means that once a day this event will be triggered and your rules accordingly.

      In my case, I use Rules Once a Day to change the site configuration to one of the Node.JS servers, create a future scheduled event in 12 hours and send me an email that the whole thing happened.

      Configuring Rules to Change a Variable

      Once you have created the event side of the rule, your next step is configuring the relevant action in this case “Set Drupal Site Variable”:

      As you can see there are just two parts here: pick the variable you want to change and what text it will be set to.

      Setting Up an Additional Rules Scheduled Component

      Since I need to have this change every 12 hours, I need two scheduled events. The first scheduled event is from Rules Once a Day. The second event gets scheduled from the first one via a Rules Component.

      A Rules Component is basically a conditional action you create that can then be trigger by other things. In this case, it gets scheduled via our original rule.

      In order to add this to our original rule, we first need to create a new component and add your reaction events. In this case, I created another “Set Drupal Site Variable” action and another reaction to send me an email.

      Packaging it all together

      Using Rules, Rules Once a Day, Rules Components and Rules Set Site Variable, the final result is a series of configurable items that work together to switch my heroku node.js site server twice a day.

      The rule configuration looks like this:

      Conclusion: You can use rules to change site configuration

      With "Rules Set Site Variables”, you change site configuration according various site events. In our case we use scheduled cron events to switch our heroku server and save some money.

      On a wider level, any site builder can now use rules to modify their site’s configuration. Using a bit more configuration and some helper modules, you can make these changes according to a set schedule.

      Live long and prosper Drupal Site Builders.

      Tags: drupalDrupal PlanetPlanet DrupalNode.jsRulesSite Builder Mark Koester @markwkoester Mark has worked on Drupal since the early days of D6. He is passionate about open source as well as entrepreneurship. When he isn't building, he enjoys traveling and speaking one of his many foreign languages. Chengdu, China
      Categories: FLOSS Project Planets
      Syndicate content