Cache tool Bundle: CacheTool Symfony2 Bundle

CacheToolBundle

This bundle allows you to integrate CacheTool with Symfony2.

Installation

{
    "require": {
        "gordalina/cachetool-bundle": "~1.0"
    }
}

Register the bundle in app/Appkernel.php:

// app/AppKernel.php

public function registerBundles()
{
    return array(
        // ...
        new CacheTool\Bundle\CacheToolBundle(),
    );
}

Enable the bundle's configuration in app/config/config.yml:

# app/config/config.yml
cache_tool: ~

Configuration

There are two adapters

  1. CLI
# app/config/config.yml
cache_tool:
    adapter: cli
  1. FastCGI
# app/config/config.yml
cache_tool:
    adapter: fastcgi
    fastcgi: 127.0.0.1:900

You can also connect by socket replacing the above by: /var/run/php5-fpm.sock.

If you don’t need apc or opcache you can disable it by setting it to false:

# app/config/config.yml
cache_tool:
    apc: false
# app/config/config.yml
cache_tool:
    opcache: false

Usage

Commands

  cachetool:apc:bin:dump                   Get a binary dump of files and user variables
  cachetool:apc:bin:load                   Load a binary dump into the APC file and user variables
  cachetool:apc:cache:info                 Shows APC user & system cache information
  cachetool:apc:cache:info:file            Shows APC file cache information
  cachetool:apc:key:delete                 Deletes an APC key
  cachetool:apc:key:exists                 Checks if an APC key exists
  cachetool:apc:key:fetch                  Shows the content of an APC key
  cachetool:apc:key:store                  Store an APC key with given value
  cachetool:apc:sma:info                   Show APC shared memory allocation information
  cachetool:cache:clear:dump               Clears APC cache (user, system or all)
  cachetool:opcache:configuration          Get configuration information about the cache
  cachetool:opcache:reset                  Resets the contents of the opcode cache
  cachetool:opcache:status                 Show summary information about the opcode cache
  cachetool:opcache:status:scripts         Show scripts in the opcode cache

Service

You can access all apc and opcode functions through the cachetool service.


$cache = $container->get('cachetool');
$cache->apc_clear_cache('both');
// or
$cache->opcache_reset();

Extending CacheTool

CacheTool depends on Proxies to provide functionality, by default when creating a CacheTool instance from the factory all proxies are enabled ApcProxy, OpcacheProxy and PhpProxy, you can customize it or extend to your will like the example below:

use CacheTool\Adapter\FastCGI;
use CacheTool\CacheTool;
use CacheTool\Proxy;

$adapter = new FastCGI('/var/run/php5-fpm.sock');
$cache = new CacheTool();
$cache->setAdapter($adapter);
$cache->addProxy(new Proxy\ApcProxy());
$cache->addProxy(new Proxy\PhpProxy());

You can read more information at CacheTool's page.

License

This bundle is released under the MIT license. See the complete license in the bundle.


Download Details:

Author: gordalina
Source Code: https://github.com/gordalina/CacheToolBundle

License: MIT license

#symfony 

What is GEEK

Buddha Community

Cache tool Bundle: CacheTool Symfony2 Bundle
Josefa  Corwin

Josefa Corwin

1659852060

A Template Language That Completely Separates Structure and Logic/Ruby

Curly

Curly is a template language that completely separates structure and logic. Instead of interspersing your HTML with snippets of Ruby, all logic is moved to a presenter class.

Installing

Installing Curly is as simple as running gem install curly-templates. If you're using Bundler to manage your dependencies, add this to your Gemfile

gem 'curly-templates'

Curly can also install an application layout file, replacing the .erb file commonly created by Rails. If you wish to use this, run the curly:install generator.

$ rails generate curly:install

How to use Curly

In order to use Curly for a view or partial, use the suffix .curly instead of .erb, e.g. app/views/posts/_comment.html.curly. Curly will look for a corresponding presenter class named Posts::CommentPresenter. By convention, these are placed in app/presenters/, so in this case the presenter would reside in app/presenters/posts/comment_presenter.rb. Note that presenters for partials are not prepended with an underscore.

Add some HTML to the partial template along with some Curly components:

<!-- app/views/posts/_comment.html.curly -->
<div class="comment">
  <p>
    {{author_link}} posted {{time_ago}} ago.
  </p>

  {{body}}

  {{#author?}}
    <p>{{deletion_link}}</p>
  {{/author?}}
</div>

The presenter will be responsible for providing the data for the components. Add the necessary Ruby code to the presenter:

# app/presenters/posts/comment_presenter.rb
class Posts::CommentPresenter < Curly::Presenter
  presents :comment

  def body
    SafeMarkdown.render(@comment.body)
  end

  def author_link
    link_to @comment.author.name, @comment.author, rel: "author"
  end

  def deletion_link
    link_to "Delete", @comment, method: :delete
  end

  def time_ago
    time_ago_in_words(@comment.created_at)
  end

  def author?
    @comment.author == current_user
  end
end

The partial can now be rendered like any other, e.g. by calling

render 'comment', comment: comment
render comment
render collection: post.comments

Curly components are surrounded by curly brackets, e.g. {{hello}}. They always map to a public method on the presenter class, in this case #hello. Methods ending in a question mark can be used for conditional blocks, e.g. {{#admin?}} ... {{/admin?}}.

Identifiers

Curly components can specify an identifier using the so-called dot notation: {{x.y.z}}. This can be very useful if the data you're accessing is hierarchical in nature. One common example is I18n:

<h1>{{i18n.homepage.header}}</h1>
# In the presenter, the identifier is passed as an argument to the method. The
# argument will always be a String.
def i18n(key)
  translate(key)
end

The identifier is separated from the component name with a dot. If the presenter method has a default value for the argument, the identifier is optional – otherwise it's mandatory.

Attributes

In addition to an identifier, Curly components can be annotated with attributes. These are key-value pairs that affect how a component is rendered.

The syntax is reminiscent of HTML:

<div>{{sidebar rows=3 width=200px title="I'm the sidebar!"}}</div>

The presenter method that implements the component must have a matching keyword argument:

def sidebar(rows: "1", width: "100px", title:); end

All argument values will be strings. A compilation error will be raised if

  • an attribute is used in a component without a matching keyword argument being present in the method definition; or
  • a required keyword argument in the method definition is not set as an attribute in the component.

You can define default values using Ruby's own syntax. Additionally, if the presenter method accepts arbitrary keyword arguments using the **doublesplat syntax then all attributes will be valid for the component, e.g.

def greetings(**names)
  names.map {|name, greeting| "#{name}: #{greeting}!" }.join("\n")
end
{{greetings alice=hello bob=hi}}
<!-- The above would be rendered as: -->
alice: hello!
bob: hi!

Note that since keyword arguments in Ruby are represented as Symbol objects, which are not garbage collected in Ruby versions less than 2.2, accepting arbitrary attributes represents a security vulnerability if your application allows untrusted Curly templates to be rendered. Only use this feature with trusted templates if you're not on Ruby 2.2 yet.

Conditional blocks

If there is some content you only want rendered under specific circumstances, you can use conditional blocks. The {{#admin?}}...{{/admin?}} syntax will only render the content of the block if the admin? method on the presenter returns true, while the {{^admin?}}...{{/admin?}} syntax will only render the content if it returns false.

Both forms can have an identifier: {{#locale.en?}}...{{/locale.en?}} will only render the block if the locale? method on the presenter returns true given the argument "en". Here's how to implement that method in the presenter:

class SomePresenter < Curly::Presenter
  # Allows rendering content only if the locale matches a specified identifier.
  def locale?(identifier)
    current_locale == identifier
  end
end

Furthermore, attributes can be set on the block. These only need to be specified when opening the block, not when closing it:

{{#square? width=3 height=3}}
  <p>It's square!</p>
{{/square?}}

Attributes work the same way as they do for normal components.

Collection blocks

Sometimes you want to render one or more items within the current template, and splitting out a separate template and rendering that in the presenter is too much overhead. You can instead define the template that should be used to render the items inline in the current template using the collection block syntax.

Collection blocks are opened using an asterisk:

{{*comments}}
  <li>{{body}} ({{author_name}})</li>
{{/comments}}

The presenter will need to expose the method #comments, which should return a collection of objects:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def comments
    @post.comments
  end
end

The template within the collection block will be used to render each item, and it will be backed by a presenter named after the component – in this case, comments. The name will be singularized and Curly will try to find the presenter class in the following order:

  • Posts::ShowPresenter::CommentPresenter
  • Posts::CommentPresenter
  • CommentPresenter

This allows you some flexibility with regards to how you want to organize these nested templates and presenters.

Note that the nested template will only have access to the methods on the nested presenter, but all variables passed to the "parent" presenter will be forwarded to the nested presenter. In addition, the current item in the collection will be passed, as well as that item's index in the collection:

class Posts::CommentPresenter < Curly::Presenter
  presents :post, :comment, :comment_counter

  def number
    # `comment_counter` is automatically set to the item's index in the collection,
    # starting with 1.
    @comment_counter
  end

  def body
    @comment.body
  end

  def author_name
    @comment.author.name
  end
end

Collection blocks are an alternative to splitting out a separate template and rendering that from the presenter – which solution is best depends on your use case.

Context blocks

While collection blocks allow you to define the template that should be used to render items in a collection right within the parent template, context blocks allow you to define the template for an arbitrary context. This is very powerful, and can be used to define widget-style components and helpers, and provide an easy way to work with structured data. Let's say you have a comment form on your page, and you'd rather keep the template inline. A simple template could look like:

<!-- post.html.curly -->
<h1>{{title}}</h1>
{{body}}

{{@comment_form}}
  <b>Name: </b> {{name_field}}<br>
  <b>E-mail: </b> {{email_field}}<br>
  {{comment_field}}

  {{submit_button}}
{{/comment_form}}

Note that an @ character is used to denote a context block. Like with collection blocks, a separate presenter class is used within the block, and a simple convention is used to find it. The name of the context component (in this case, comment_form) will be camel cased, and the current presenter's namespace will be searched:

class PostPresenter < Curly::Presenter
  presents :post
  def title; @post.title; end
  def body; markdown(@post.body); end

  # A context block method *must* take a block argument. The return value
  # of the method will be used when rendering. Calling the block argument will
  # render the nested template. If you pass a value when calling the block
  # argument it will be passed to the presenter.
  def comment_form(&block)
    form_for(Comment.new, &block)
  end

  # The presenter name is automatically deduced.
  class CommentFormPresenter < Curly::Presenter
    # The value passed to the block argument will be passed in a parameter named
    # after the component.
    presents :comment_form

    # Any parameters passed to the parent presenter will be forwarded to this
    # presenter as well.
    presents :post

    def name_field
      @comment_form.text_field :name
    end

    # ...
  end
end

Context blocks were designed to work well with Rails' helper methods such as form_for and content_tag, but you can also work directly with the block. For instance, if you want to directly control the value that is passed to the nested presenter, you can call the call method on the block yourself:

def author(&block)
  content_tag :div, class: "author" do
    # The return value of `call` will be the result of rendering the nested template
    # with the argument. You can post-process the string if you want.
    block.call(@post.author)
  end
end

Context shorthand syntax

If you find yourself opening a context block just in order to use a single component, e.g. {{@author}}{{name}}{{/author}}, you can use the shorthand syntax instead: {{author:name}}. This works for all component types, e.g.

{{#author:admin?}}
  <p>The author is an admin!</p>
{{/author:admin?}}

The syntax works for nested contexts as well, e.g. {{comment:author:name}}. Any identifier and attributes are passed to the target component, which in this example would be {{name}}.

Setting up state

Although most code in Curly presenters should be free of side effects, sometimes side effects are required. One common example is defining content for a content_for block.

If a Curly presenter class defines a setup! method, it will be called before the view is rendered:

class PostPresenter < Curly::Presenter
  presents :post

  def setup!
    content_for :title, post.title

    content_for :sidebar do
      render 'post_sidebar', post: post
    end
  end
end

Escaping Curly syntax

In order to have {{ appear verbatim in the rendered HTML, use the triple Curly escape syntax:

This is {{{escaped}}.

You don't need to escape the closing }}.

Comments

If you want to add comments to your Curly templates that are not visible in the rendered HTML, use the following syntax:

{{! This is some interesting stuff }}

Presenters

Presenters are classes that inherit from Curly::Presenter – they're usually placed in app/presenters/, but you can put them anywhere you'd like. The name of the presenter classes match the virtual path of the view they're part of, so if your controller is rendering posts/show, the Posts::ShowPresenter class will be used. Note that Curly is only used to render a view if a template can be found – in this case, at app/views/posts/show.html.curly.

Presenters can declare a list of accepted variables using the presents method:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
end

A variable can have a default value:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
  presents :comment, default: nil
end

Any public method defined on the presenter is made available to the template as a component:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author_link
    # You can call any Rails helper from within a presenter instance:
    link_to author.name, profile_path(author), rel: "author"
  end

  private

  # Private methods are not available to the template, so they're safe to
  # use.
  def author
    @post.author
  end
end

Presenter methods can even take an argument. Say your Curly template has the content {{t.welcome_message}}, where welcome_message is an I18n key. The following presenter method would make the lookup work:

def t(key)
  translate(key)
end

That way, simple ``functions'' can be added to the Curly language. Make sure these do not have any side effects, though, as an important part of Curly is the idempotence of the templates.

Layouts and content blocks

Both layouts and content blocks (see content_for) use yield to signal that content can be inserted. Curly works just like ERB, so calling yield with no arguments will make the view usable as a layout, while passing a Symbol will make it try to read a content block with the given name:

# Given you have the following Curly template in
# app/views/layouts/application.html.curly
#
#   <html>
#     <head>
#       <title>{{title}}</title>
#     </head>
#     <body>
#       <div id="sidebar">{{sidebar}}</div>
#       {{body}}
#     </body>
#   </html>
#
class ApplicationLayout < Curly::Presenter
  def title
    "You can use methods just like in any other presenter!"
  end

  def sidebar
    # A view can call `content_for(:sidebar) { "some HTML here" }`
    yield :sidebar
  end

  def body
    # The view will be rendered and inserted here:
    yield
  end
end

Rails helper methods

In order to make a Rails helper method available as a component in your template, use the exposes_helper method:

class Layouts::ApplicationPresenter < Curly::Presenter
  # The components {{sign_in_path}} and {{root_path}} are made available.
  exposes_helper :sign_in_path, :root_path
end

Testing

Presenters can be tested directly, but sometimes it makes sense to integrate with Rails on some levels. Currently, only RSpec is directly supported, but you can easily instantiate a presenter:

SomePresenter.new(context, assigns)

context is a view context, i.e. an object that responds to render, has all the helper methods you expect, etc. You can pass in a test double and see what you need to stub out. assigns is the hash containing the controller and local assigns. You need to pass in a key for each argument the presenter expects.

Testing with RSpec

In order to test presenters with RSpec, make sure you have rspec-rails in your Gemfile. Given the following presenter:

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def body
    Markdown.render(@post.body)
  end
end

You can test the presenter methods like this:

# You can put this in your `spec_helper.rb`.
require 'curly/rspec'

# spec/presenters/posts/show_presenter_spec.rb
describe Posts::ShowPresenter, type: :presenter do
  describe "#body" do
    it "renders the post's body as Markdown" do
      assign(:post, double(:post, body: "**hello!**"))
      expect(presenter.body).to eq "<strong>hello!</strong>"
    end
  end
end

Note that your spec must be tagged with type: :presenter.

Examples

Here is a simple Curly template – it will be looked up by Rails automatically.

<!-- app/views/posts/show.html.curly -->
<h1>{{title}}<h1>
<p class="author">{{author}}</p>
<p>{{description}}</p>

{{comment_form}}

<div class="comments">
  {{comments}}
</div>

When rendering the template, a presenter is automatically instantiated with the variables assigned in the controller or the render call. The presenter declares the variables it expects with presents, which takes a list of variables names.

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author
    link_to(@post.author.name, @post.author, rel: "author")
  end

  def description
    Markdown.new(@post.description).to_html.html_safe
  end

  def comments
    render 'comment', collection: @post.comments
  end

  def comment_form
    if @post.comments_allowed?
      render 'comment_form', post: @post
    else
      content_tag(:p, "Comments are disabled for this post")
    end
  end
end

Caching

Caching is handled at two levels in Curly – statically and dynamically. Static caching concerns changes to your code and templates introduced by deploys. If you do not wish to clear your entire cache every time you deploy, you need a way to indicate that some view, helper, or other piece of logic has changed.

Dynamic caching concerns changes that happen on the fly, usually made by your users in the running system. You wish to cache a view or a partial and have it expire whenever some data is updated – usually whenever a specific record is changed.

Dynamic Caching

Because of the way logic is contained in presenters, caching entire views or partials by the data they present becomes exceedingly straightforward. Simply define a #cache_key method that returns a non-nil object, and the return value will be used to cache the template.

Whereas in ERB you would include the cache call in the template itself:

<% cache([@post, signed_in?]) do %>
  ...
<% end %>

In Curly you would instead declare it in the presenter:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def cache_key
    [@post, signed_in?]
  end
end

Likewise, you can add a #cache_duration method if you wish to automatically expire the fragment cache:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_duration
    30.minutes
  end
end

In order to set any cache option, define a #cache_options method that returns a Hash of options:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_options
    { compress: true, namespace: "my-app" }
  end
end

Static Caching

Static caching will only be enabled for presenters that define a non-nil #cache_key method (see Dynamic Caching.)

In order to make a deploy expire the cache for a specific view, set the version of the view to something new, usually by incrementing by one:

class Posts::ShowPresenter < Curly::Presenter
  version 3

  def cache_key
    # Some objects
  end
end

This will change the cache keys for all instances of that view, effectively expiring the old cache entries.

This works well for views, or for partials that are rendered in views that themselves are not cached. If the partial is nested within a view that is cached, however, the outer cache will not be expired. The solution is to register that the inner partial is a dependency of the outer one such that Curly can automatically deduce that the outer partial cache should be expired:

class Posts::ShowPresenter < Curly::Presenter
  version 3
  depends_on 'posts/comment'

  def cache_key
    # Some objects
  end
end

class Posts::CommentPresenter < Curly::Presenter
  version 4

  def cache_key
    # Some objects
  end
end

Now, if the version of Posts::CommentPresenter is bumped, the cache keys for both presenters would change. You can register any number of view paths with depends_on.

Curly integrates well with the caching mechanism in Rails 4 (or Cache Digests in Rails 3), so the dependencies defined with depends_on will be tracked by Rails. This will allow you to deploy changes to your templates and have the relevant caches automatically expire.

Thanks

Thanks to Zendesk for sponsoring the work on Curly.

Contributors

Build Status


Author: zendesk
Source code: https://github.com/zendesk/curly

#ruby   #ruby-on-rails 

50+ Useful DevOps Tools

The article comprises both very well established tools for those who are new to the DevOps methodology.

What Is DevOps?

The DevOps methodology, a software and team management approach defined by the portmanteau of Development and Operations, was first coined in 2009 and has since become a buzzword concept in the IT field.

DevOps has come to mean many things to each individual who uses the term as DevOps is not a singularly defined standard, software, or process but more of a culture. Gartner defines DevOps as:

“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

As you can see from the above definition, DevOps is a multi-faceted approach to the Software Development Life Cycle (SDLC), but its main underlying strength is how it leverages technology and software to streamline this process. So with the right approach to DevOps, notably adopting its philosophies of co-operation and implementing the right tools, your business can increase deployment frequency by a factor of 30 and lead times by a factor of 8000 over traditional methods, according to a CapGemini survey.

The Right Tools for the Job

This list is designed to be as comprehensive as possible. The article comprises both very well established tools for those who are new to the DevOps methodology and those tools that are more recent releases to the market — either way, there is bound to be a tool on here that can be an asset for you and your business. For those who already live and breathe DevOps, we hope you find something that will assist you in your growing enterprise.

With such a litany of tools to choose from, there is no “right” answer to what tools you should adopt. No single tool will cover all your needs and will be deployed across a variety of development and Operational teams, so let’s break down what you need to consider before choosing what tool might work for you.

  • Plan and collaborate: Before you even begin the SDLC, your business needs to have a cohesive idea of what tools they’ll need to implement across your teams. There are even DevOps tools that can assist you with this first crucial step.
  • Build: Here you want tools that create identically provisioned environments. The last you need is to hear “But it works for me on my computer”
  • Automation: This has quickly become a given in DevOps, but automation will always drastically increase production over manual methods.
  • Continuous Integration: Tools need to provide constant and immediate feedback, several times a day but not all integrations are implemented equally, will the tool you select be right for the job?
  • Deployment: Deployments need to be kept predictable, smooth, and reliable with minimal risks, automation will also play a big part in this process.

With all that in mind, I hope this selection of tools will aid you as your business continues to expand into the DevOps lifestyle.

Tools Categories List:

Infrastructure As Code

Continuous Integration and Delivery

Development Automation

Usability Testing

Database and Big Data

Monitoring

Testing

Security

Helpful CLI Tools

Development

Visualization

Infrastructure As Code

#AWSCloudFormation

1. AWS CloudFormation

AWS CloudFormation is an absolute must if you are currently working, or planning to work, in the AWS Cloud. CloudFormation allows you to model your AWS infrastructure and provision all your AWS resources swiftly and easily. All of this is done within a JSON or YAML template file and the service comes with a variety of automation features ensuring your deployments will be predictable, reliable, and manageable.

Link: https://aws.amazon.com/cloudformation/

2. Azure Resource Manager

Azure Resource Manager (ARM) is Microsoft’s answer to an all-encompassing IAC tool. With its ARM templates, described within JSON files, Azure Resource Manager will provision your infrastructure, handle dependencies, and declare multiple resources via a single template.

Link: https://azure.microsoft.com/en-us/features/resource-manager/

#Google Cloud Deployment Manager

3. Google Cloud Deployment Manager

Much like the tools mentioned above, Google Cloud Deployment Manager is Google’s IAC tool for the Google Cloud Platform. This tool utilizes YAML for its config files and JINJA2 or PYTHON for its templates. Some of its notable features are synchronistic deployment and ‘preview’, allowing you an overhead view of changes before they are committed.

Link: https://cloud.google.com/deployment-manager/

4. Terraform

Terraform is brought to you by HashiCorp, the makers of Vault and Nomad. Terraform is vastly different from the above-mentioned tools in that it is not restricted to a specific cloud environment, this comes with increased benefits for tackling complex distributed applications without being tied to a single platform. And much like Google Cloud Deployment Manager, Terraform also has a preview feature.

Link: https://www.terraform.io/

#Chef

5. Chef

Chef is an ideal choice for those who favor CI/CD. At its heart, Chef utilizes self-described recipes, templates, and cookbooks; a collection of ready-made templates. Cookbooks allow for consistent configuration even as your infrastructure rapidly scales. All of this is wrapped up in a beautiful Ruby-based DSL pie.

Link: https://www.chef.io/products/chef-infra/

#Ansible

#tools #devops #devops 2020 #tech tools #tool selection #tool comparison

Sunny  Kunde

Sunny Kunde

1597848060

Top 12 Most Used Tools By Developers In 2020

rameworks and libraries can be said as the fundamental building blocks when developers build software or applications. These tools help in opting out the repetitive tasks as well as reduce the amount of code that the developers need to write for a particular software.

Recently, the Stack Overflow Developer Survey 2020 surveyed nearly 65,000 developers, where they voted their go-to tools and libraries. Here, we list down the top 12 frameworks and libraries from the survey that are most used by developers around the globe in 2020.

(The libraries are listed according to their number of Stars in GitHub)

1| TensorFlow

**GitHub Stars: **147k

Rank: 5

**About: **Originally developed by researchers of Google Brain team, TensorFlow is an end-to-end open-source platform for machine learning. It has a comprehensive, flexible ecosystem of tools, libraries, and community resources that lets researchers push the state-of-the-art research in ML. It allows developers to easily build and deploy ML-powered applications.

Know more here.

2| Flutter

**GitHub Stars: **98.3k

**Rank: **9

About: Created by Google, Flutter is a free and open-source software development kit (SDK) which enables fast user experiences for mobile, web and desktop from a single codebase. The SDK works with existing code and is used by developers and organisations around the world.


#opinions #developer tools #frameworks #java tools #libraries #most used tools by developers #python tools

davis mike

1626331037

Caching In WordPress: What You Need to Learn?

WordPress caching has nothing new to showcase in this context. WordPress websites also run on a specific server system and you have to make sure these servers work well for user engagement. So caching can help your website server work effectively to serve too many visitors collectively. The commonly requested items can be converted into varied copies that the website server doesn’t want to showcase every time to every website visitor. Classification of Caching is usually divided into two kinds. The Client-Side Caching & the Server Side Caching. Where client-side caching has nothing to do with your website, Server Side Caching is usually its opposite. Read more on https://bit.ly/3rbqvVh

#caching plugins #server side caching #client side caching #wordpress websites #wordpress caching

Cache tool Bundle: CacheTool Symfony2 Bundle

CacheToolBundle

This bundle allows you to integrate CacheTool with Symfony2.

Installation

{
    "require": {
        "gordalina/cachetool-bundle": "~1.0"
    }
}

Register the bundle in app/Appkernel.php:

// app/AppKernel.php

public function registerBundles()
{
    return array(
        // ...
        new CacheTool\Bundle\CacheToolBundle(),
    );
}

Enable the bundle's configuration in app/config/config.yml:

# app/config/config.yml
cache_tool: ~

Configuration

There are two adapters

  1. CLI
# app/config/config.yml
cache_tool:
    adapter: cli
  1. FastCGI
# app/config/config.yml
cache_tool:
    adapter: fastcgi
    fastcgi: 127.0.0.1:900

You can also connect by socket replacing the above by: /var/run/php5-fpm.sock.

If you don’t need apc or opcache you can disable it by setting it to false:

# app/config/config.yml
cache_tool:
    apc: false
# app/config/config.yml
cache_tool:
    opcache: false

Usage

Commands

  cachetool:apc:bin:dump                   Get a binary dump of files and user variables
  cachetool:apc:bin:load                   Load a binary dump into the APC file and user variables
  cachetool:apc:cache:info                 Shows APC user & system cache information
  cachetool:apc:cache:info:file            Shows APC file cache information
  cachetool:apc:key:delete                 Deletes an APC key
  cachetool:apc:key:exists                 Checks if an APC key exists
  cachetool:apc:key:fetch                  Shows the content of an APC key
  cachetool:apc:key:store                  Store an APC key with given value
  cachetool:apc:sma:info                   Show APC shared memory allocation information
  cachetool:cache:clear:dump               Clears APC cache (user, system or all)
  cachetool:opcache:configuration          Get configuration information about the cache
  cachetool:opcache:reset                  Resets the contents of the opcode cache
  cachetool:opcache:status                 Show summary information about the opcode cache
  cachetool:opcache:status:scripts         Show scripts in the opcode cache

Service

You can access all apc and opcode functions through the cachetool service.


$cache = $container->get('cachetool');
$cache->apc_clear_cache('both');
// or
$cache->opcache_reset();

Extending CacheTool

CacheTool depends on Proxies to provide functionality, by default when creating a CacheTool instance from the factory all proxies are enabled ApcProxy, OpcacheProxy and PhpProxy, you can customize it or extend to your will like the example below:

use CacheTool\Adapter\FastCGI;
use CacheTool\CacheTool;
use CacheTool\Proxy;

$adapter = new FastCGI('/var/run/php5-fpm.sock');
$cache = new CacheTool();
$cache->setAdapter($adapter);
$cache->addProxy(new Proxy\ApcProxy());
$cache->addProxy(new Proxy\PhpProxy());

You can read more information at CacheTool's page.

License

This bundle is released under the MIT license. See the complete license in the bundle.


Download Details:

Author: gordalina
Source Code: https://github.com/gordalina/CacheToolBundle

License: MIT license

#symfony