Nandito.hu's RSS Feed

Create a site with Gatsby + Sanity + Tailblocks

Wed, 10 Jun 2020 04:45:59 GMT

In this post I share my learnings on how to create Sanity schemas, deploy them and use as data source for a Gatsby site. To save time on coding design, I’m going to use the ready-to-use Tailwind CSS blocks: Tailblocks.

Sanity

For more details, follow the official docs’ instructions on Getting started with Sanity CLI. TL;DR here’s the code:

Bootstrap project

$ npm install -g @sanity/cli
$ sanity init
$ sanity start

Schema defs

Schemas needs to be defined in the schemas/schema.js

It’s practical to add each schema document or object in separated files and include them in the schema types list:

import createSchema from 'part:@sanity/base/schema-creator'
import schemaTypes from 'all:part:@sanity/base/schema-type'
import feature from './feature'
import portfolioImage from './portfolio-image'

export default createSchema({
  name: 'default',
  types: schemaTypes.concat([
    // here
    feature,
    portfolioImage,
  ]),
})

Types

Sanity has the following types:

string, number, boolean, datetime, url
custom types via object types

Create document type

These will appear in the studio and we can create multiple docs using their structure.

Here as example (schemas/feature.js)

export default {
  title: 'Feature',
  name: 'feature',
  type: 'document',
  fields: [
    {
      title: 'Title',
      name: 'title',
      type: 'string'
    },
    {
      title: 'Description',
      name: 'description',
      type: 'string'
    },
    {
      title: 'Cover',
      name: 'cover',
      type: 'image'
    },
  ]
}

Create object type

This defines a shape of a field, can be assigned to a document.

export default {
  title: 'Portfolio image',
  name: 'portfolioImage',
  type: 'object',
  fields: [
    {
      title: 'Image',
      name: 'image',
      type: 'image'
    },
    {
      title: 'Caption',
      name: 'caption',
      type: 'string'
    },
    {
      title: 'Date of creation',
      name: 'dateOfCreation',
      type: 'datetime'
    }
  ]
}

Add this to the schemas/schema.js file’s schemaTypes.concat(). Then we can add field to another schema.

{
  title: 'Images',
  name: 'images',
  type: 'array',
  of: [{ type: 'portfolioImage' }],
},

Deploy Sanity Studio

$ sanity deploy

Then our Studio will be available on the <project>.sanity.studio URL. If we change something in the studio locally, this is also how we would upload changes.

Gatsby

Create app, set up source

Create bare Gatsby app using the hello world starter. This one doesn’t contain any boostrap code and dependencies, but it’s ok, we can add them. First let’s add Sanity source plugin.

$ gatsby new my-site https://github.com/gatsbyjs/gatsby-starter-hello-world
$ npm i gatsby-source-sanity --save

Configure Sanity plugin in gatsby-config.js

module.exports = {
  plugins: [
    {
      resolve: 'gatsby-source-sanity',
      options: {
        // these values can be found in manage.sanity.io once the app is deployed
        projectId: 'project-id',
        dataset: 'production',
      },
    },
  ],
}

Deploy GraphQL API for Sanity

$ sanity graphql deploy

See data in Gatsby

Now the Sanity data should be visible in Gatsby’s GraphiQL. Start the app by running

$ gatsby develop

Explore schema and query data on the http://localhost:8000/__graphql site

Find more info in the source plugin’s site: gatsby-source-sanity

Tailblocks

Setup Tailwind CSS

Install dependencies in the repo

$ npm install --save gatsby-plugin-postcss tailwindcss autoprefixer

Update Gatsby config (gatsby-config.js)

module.exports = {
  plugins: [`gatsby-plugin-postcss`],
}

Add postcss config: create a postcss.config.js file in the project root with the following content:

module.exports = () => ({
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
  ],
})

Create a css file (eg. root.css) with these imports

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

Import the recently created css to our app, somewhere on the top of the tree to make it available everywhere

import React from 'react'
import '../components/root.css'

function App() {
  return (
    <div className="bg-gray-900">
      Tailwind classes should work now! 🎉
    </div>
  )
}

Using Tailblocks

Visit https://mertjf.github.io/tailblocks/ site and select an element
Click “View code” in the top bar and then copy the code
Paste it to your app
Rename all class="" attributes to className="" and transform “kebab-case” attributes names with “camelCase”.

Resources

Installation - Tailwind CSS

Tailwind CSS

gatsbyjs/gatsby

tailblocks - Ready-to-use Tailwind CSS blocks

Replace hardcoded data

Once we have built the site using Tailblocks, it’s time to replace the hardcoded example text with data we get from Sanity.

Let’s say we have a Features block. We can create a Features component in React, get and map data right in the component like this:

import React from 'react'
import { graphql, useStaticQuery } from 'gatsby'
import Img from 'gatsby-image'

function Features() {
  const { allSanityFeature } = useStaticQuery(graphql`
    {
      allSanityFeature {
        nodes {
          title
          description
          id
          cover {
            asset {
              fixed(width: 80) {
                ...GatsbySanityImageFixed
              }
            }
          }
        }
      }
    }
  `)

  return (
    <section className="text-gray-500 bg-gray-900 body-font">
      <div className="container px-5 py-24 mx-auto">
        <div className="flex flex-wrap sm:-m-4 -mx-4 -mb-10 -mt-4">
          {allSanityFeature.nodes.map(feature => (
            <div
              className="p-4 md:w-1/3 md:mb-0 mb-6 flex flex-col text-center items-center"
              key={feature.id}
            >
              <div className="w-20 h-20 inline-flex items-center justify-center rounded-full bg-gray-800 text-purple-400 mb-5 flex-shrink-0">
                <Img fixed={feature.cover.asset.fixed} />
              </div>

              <div className="flex-grow">
                <h2 className="text-white text-lg title-font font-medium mb-3">
                  {feature.title}
                </h2>

                <p className="leading-relaxed text-base">
                  {feature.description}
                </p>
              </div>
            </div>
          ))}
        </div>
      </div>
    </section>
  )
}

export default Features

Don’t forget to install gatsby-image to make responsive, lazy-loaded image rendering work.

$ npm install gatsby-image --save

Summary

Now we have a real Jamstack site with a headless CMS and a server side rendered responsive frontend! As a next step we can set up hosting and auto rebuild using webhooks.

Other resources

Cover image by PixaBay

Self-hosted, cookieless analytics for free

Mon, 04 May 2020 19:03:53 GMT

Cover image is copied from the Ackee’s GitHub repo

Why?

Most sites I’ve built are using Google Analytics (GA), the free and very feature-rich website analytics tool. It’s easy to set up and shows real time data on complex charts. But GA tracks the users more extensively than I need for a personal blog. It also requires a strict privacy policy and users need to accept that notice to let the tracking start.

I did think of the “No tracking” option. The browsers’ tracking blockers make client-side trackers less and less accurate. However, seeing even a little bit (maybe not-that-accurate) activity on my site still motivates me to keep going with it.

Another option was server-side analytics. They are fast, private and accurate. But for a non-profit personal blog with very few visitors it simply isn’t worth paying $7-9/mo to see the stats.

Goals

I defined what would be the ideal tracking for my site:

Open source
Does not use cookies (no cookies -> no cookie policy overhead)
Cheap (possibly free) hosting

My choice

When I was searching for alternatives I found Alec Brunelle’s Quit Google Analytics and use self-hosted Gatsby statistics with Ackee post on Medium. I tried Ackee’s demo and it collects exactly the data I need.

So I decided to try:

Analytics tool: Ackee (✅ open source; ✅ no cookies)
Hosting: Google Cloud Platform’s (GCP) always free tier (f1-micro)

I tried to deploy to Heroku (as Alec did in his post) but as Heroku asked for my credit card data, I was not sure if it can run on a free dyno. Or maybe I’ve just reached the free limit with other hobby projects.

Steps

Set up the Virtual Machine (VM)

During the VM creation GCP asked for my credit card details but promised not to charge without permission. They gave $300 free credit for the first year, too.

The services I’m using cost $0.00 / mo.

It’s up and running for 8 days now and billing report shows $0.00 for this month. I still have all of the $300 free credit.

Log in to Google Cloud Platform: https://console.cloud.google.com/getting-started
Create project (name could be anything you want)
Go to Compute Engine >> VM Instances

Enable free tier
Create new VM: for the always-free, select:
- us-central1 (Iowa) region (us-west1 and us-east1 is free, too)
- f1-micro (1 vCPU, 0.6 GB memory)
- Debian 9 (other Linux distro could also work but make sure to use one with free license if you want to keep it free)
- “Allow full access to all Cloud APIs” access scope
- Enable both HTTP and HTTPS traffic on the Firewall

Reserve Static IP: go to VPC network > External IP addresses on the GCP dashboard, then select the instance and hit “Reserve Static Address” in the top bar.

Install Ackee

SSH to the VM in the web by clicking the SSH button in the instance list of the VM Instances page.

Install Node 12 LTS (code is copied from here)

# Using Debian, as root
curl -sL https://deb.nodesource.com/setup_12.x | bash -
apt-get install -y nodejs

Install yarn
```
npm install -g yarn
```

Install Mongo DB: follow the instructions in their official docs. For me it worked without any issue, here are the commands:

wget -qO - https://www.mongodb.org/static/pgp/server-4.2.asc | sudo apt-key add -
echo "deb http://repo.mongodb.org/apt/debian stretch/mongodb-org/4.2 main" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.2.list
sudo apt-get update
sudo apt-get install -y mongodb-org
sudo systemctl start mongod
sudo systemctl status mongod # just to see if it works
sudo systemctl enable mongod # start mongo after reboot

Make the site available

Set a domain: my domain uses a different DNS provider. I just created a subdomain and set an A record that points to the VM’s reserved static IP address.

Install NGINX (I used this instructions)

sudo apt-get update
sudo apt-get install nginx
sudo systemctl enable nginx

Set NGINX config, details here

Install Certbot for Let’s Encrypt (more details here)

sudo apt-get install certbot python-certbot-nginx
sudo certbot --nginx
sudo certbot renew --dry-run # To test automatic renewal

Run the app as a service: I followed these instuctions.

Create the file /lib/systemd/system/ackee.service with the following contents:

[Unit]
Description=Ackee App
After=network-online.target

[Service]
Restart=on-failure
WorkingDirectory=/home/nandor/Ackee
ExecStart=/usr/bin/node src/index.js

[Install]
WantedBy=mutli-user.target

Reload daemon

systemctl daemon-reload

Let it run on reboot

systemctl enable ackee

Trial and error

First I wanted to run the Dockerized app in the f1-micro instance. I used the Container-optimized OS. But it seems that ~580 MB RAM is not enough to run the Mongo DB and the Ackee containers at the same time (+ an nginx reverse proxy + the GCP’s logger container).

After struggling for a few hours I decided to try to install the apps directly to Debian. This way everything worked on the first try.

Conclusion

Well, I’ve spent several evenings to move my analytics from Google Analytics to another Google service (Google Cloud Platform). It’s still Google, but the data now is inside a VM’s database, not in GA directly.

Testing React render props with Enzyme

Thu, 07 Jun 2018 18:50:00 GMT

In React 16.3.0 they announced the new, official context API as a replacement of the previous, experimental one. Here, the context consumer requires function as a child to use values from the context. Testing these consumers seemed a bit tricky but here’s a workaround to do that.

In the examples I use Jest with Enzyme to test an app created by Create React App. The official documentation has a step-by-step guide how to set up these framework easily.

The problem

When we have a render prop in the shallow rendered React component test, we cannot see its name.

So when we have this in the Header component:

const Header = () => (
  <Consumer>
    {({ language }) => (
      <header>
        <h1>{dictionary['GREETING'][language]}</h1>
      </header>
    )}
  </Consumer>
)

this in the test:

describe('Header', () => {
  it('renders the Header', () => {
    const wrapper = shallow(<Header />)

    console.log(wrapper.debug())
  })
})

we get this as a result:

<[object Object]>
  <undefined />
</[object Object]>

Neither find() nor findWhere() functions work here as currently they cannot get the header or h1 tags in this state.

A solution

When we use render props, the wrapped component will be the result of the wrapper’s children prop function and it gets some values as a parameter. In the preceding example the consumer passes an object with the language code to the header to show the greeting in the current language.

When we need to test this children prop, we can do that by getting and rendering it again:

it('renders the Header', () => {
  const outer = shallow(<Header />)
  const Children = outer.prop('children')
  const wrapper = shallow(<Children />)

  console.log(wrapper.debug())
})

Here, the output shows the correct element names:

<header>
  <h1 />
</header>

Now we can use the Enzyme’s find() function to write some tests and make sure the Header component always works.

it('renders the Header', () => {
  const outer = shallow(<Header />)
  const Children = outer.prop('children')
  const wrapper = shallow(<Children />)

  expect(wrapper.find('header')).toHaveLength(1)
  expect(wrapper.find('h1')).toHaveLength(1)
})

It is working! Now we can be sure that our Header component will always have header and h1 tags in the future - or else this test will fail.

Testing the passed values

The h1 tags do not render any value in this current state because there is no value passed by the consumer. Luckily we can also manipulate this passed value directly from our test.

it('renders the title on the proper language', () => {
  const outer = shallow(<Header/>)
  const Children = outer.prop('children')
  const wrapper = shallow(<Children language="en"/>)

  console.log(wrapper.debug())
})

Now as we can see in the console, heading tag gets value:

<header>
  <h1>
    Hello World!
  </h1>
</header>

Let’s write some test expectations to make sure it works in the future:

it('renders the title on the proper language', () => {
  const outer = shallow(<Header/>)
  const Children = outer.prop('children')
  const wrapper = shallow(<Children language="en"/>)

  expect(wrapper.find('h1').text()).toBe(dictionary['GREETING']['en'])
  expect(wrapper.find('h1').text()).toBe('Hello World!')
})

In the snippet above you may prefer to expect the rendered translated text defined as a reference to the dictionary (dictionary['GREETING']['en']) or as a string ('Hello World!'). If you use the former, your test won’t break when someone updates the dictionary, while the latter will do.

This way we test that:

Header component does not crash It renders all the expected tags: header and h1 It uses the value it gets from the context

I’m not sure if this is the best way to test components with the new context API. But currently it is good enough to make sure my components work as expected.

If we have several components using the context consumer, it is a good practice to create a helper function for the tests. Here’s an example:

export const shallowRenderProps = (Component, injectedProps) => {
  const outer = shallow(Component)
  const Children = outer.prop('children')
  const childrenWrapper = shallow(<Children{...injectedProps}/>)
  const wrapper = childrenWrapper.shallow()

  return wrapper
}

Now we can render the Heading components in the test like this:

it('renders the title on the proper language', () => {
  const wrapper = shallowRenderProps(<Header/>,{language:'en'})

  expect(wrapper.find('h1').text()).toBe(dictionary['GREETING']['en'])
  expect(wrapper.find('h1').text()).toBe('Hello World!')
})

You can find the code on GitHub.

How to learn React

Thu, 26 Apr 2018 18:54:00 GMT

A couple days ago I was asked to give some ideas about how to dig into JavaScript and React to be able to join a team and deliver code as a frontend developer. I’ve collected my favorite resources, feel free to check them out.

Videos

A screencast tutorial is like sitting next to a teacher who explains what she/he is doing. If something is not clear it can be replayed or the playing speed can be adjusted.

The first React tutorial I saw is React for Beginners by Wes Bos. It was a good start and as I see Wes Bos keeps it up-to-date.

I’ve learnt a lot from Egghead.io videos. They have free resources from big names of the JavaScript community, for example

The Beginner’s Guide to ReactJS by Kent C. Dodds
Start Learning React by Joe Maddalone
Getting Started with Redux by Dan Abramov

I also have an annual subscription here, they upload quality content frequently and for me this is absolutely worth its price.

I also recommend the JavaScript: Understanding the Weird Parts course on Udemy. This is a huge collection of videos about JavaScript in general. It helped me a lot to write code with more confidence.

Books

I’ve bought some React books, it feels good to have some on my e-book reader. Here are my favorites:

React Design Patterns and Best Practices by Michele Bertoli
SurviveJS - React by Juho Vepsäläinen
Progressive Web Apps with React by Scott Domes
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

The Clean Code book is not about React but it is a mandatory book for all developers. I recommend the whole Robert C. Martin series.

Blogs

Medium is one of the best resources to follow technologies, influencers, developers. You can read announcements, case studies, tutorials, best practices, general and unique problems with solutions. This platform has a pretty good recommending engine, it will show you posts based on your “claps”.

YouTube channels

Fun Fun Function - This is definitely my favorite YouTube channel. This guy has many high quality videos not just in React, but also in pure JavaScript.
React Amsterdam - They upload the React Amsterdam conference talks here.
LevelUpTuts
Front End Center - This channel’s videos are about concepts, they are very useful if you want to write clean code.
ReactCasts - Quick screencasts with nice narrations.
Coding Tech - You can find all kinds of coding videos here, not just React - mostly conference talks.

GitHub

I follow some developers on GitHub to see their activities and recommendations (stars) on my GitHub feed.

Do it

Of course, reading all the books and watching all the videos won’t transform anyone to a decent developer. It is mandatory to practice writing code so I encourage everyone to type (not just copy-paste, type!) the code and try them out. This is the best way to learn and strengthen the muscle memory.

Later, if you encounter a problem that you’d solved before in one of your practices or tutorials, it is much easier to find the solution in your developer machine’s folder than to find that video and that part of it where they solve that problem. And for sure it is even harder if you watched it weeks or months ago.

Set up GraphiQL IDE for Tipe

Mon, 05 Feb 2018 05:08:00 GMT

In a previous article I mentioned Tipe which is a GraphQL software as a service provider “under construction”. Well, their beta version has been available since the 2nd of February and as they have a cute cat logo, I signed up immediately. I saw that currently it’s quite hard to check the GraphQL schema of the endpoint. Although the GraphQL playground implementation is on their roadmap, it’s not available yet. So I decided to set up a GraphiQL IDE locally for Tipe.

The code is available on GitHub: https://github.com/nandito/tipe-graphiql

Tipe

So far I’ve just been playing with the Tipe’s admin interface. I’ve created some folders, templates and documents. I miss many things from their service but I know they are in beta phase so I would not complain about anything.

Create React App

Tipe provides an API endpoint and we have to use custom request headers to get our project’s data. I used create-react-app for bootstrapping the project. This way I saved the time of the build configuration.

$ npm install create-react-app -g # install create-react-app globally
$ create-react-app tipe-graphiql

This creates the tipe-graphiql project folder with all the necessary React configurations.

Add GraphiQL dependency

Next I added graphiql as a dependency and ran the installer script.

$ cd tipe-graphiql
$ yarn add graphiql # or npm install graphiql --save
$ yarn install # or npm install

Now that everything is installed, it’s time to add GraphiQL to the app and remove all the unused Create React App code.

Replace sample React code with GraphiQL

Edit the src/index.js file: remove the service worker and the imported App component, then paste the code from the GraphiQL’s GitHub page.

import React from 'react';
import ReactDOM from 'react-dom';
import GraphiQL from 'graphiql';
import fetch from 'isomorphic-fetch';
import './index.css';
import '../node_modules/graphiql/graphiql.css'

const API_KEY = 'your_api_key';
const ORG_SECRET_KEY = 'your_org_secret';

function graphQLFetcher(graphQLParams) {
  return fetch('https://api.tipe.io/graphql', {
    method: 'post',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': API_KEY,
      'Tipe-Id': ORG_SECRET_KEY,
    },
    body: JSON.stringify(graphQLParams),
  }).then(response => response.json());
}

ReactDOM.render(, document.getElementById('root'));

I used the Tipe’s GraphQL API request docs to set up the request credentials. The endpoint url (https://api.tipe.io/graphql) seems generic, that’s why I didn’t extract it as a constant. The API_KEY and ORG_SECRET_KEY constants should be replaced with your own credentials. You can find some guides in the linked docs to get them.

I also had to include the GraphiQL styles by importing its css file from the node_modules folder.

Then I set the height in the src/index.css to stretch the IDE to fill the whole page.

body {
  margin: 0;
  padding: 0;
  font-family: sans-serif;
}

html, body, #root {
  height: 100%;
}

Clean up

As I don’t use the App component and the service worker, their files can be removed.

$ rm ./src/App.*
$ rm ./src/logo.svg
$ rm ./src/registerServiceWorker.js

Run the app locally

Now the app server can be started and when it runs, the GraphiQL IDE is available in the browser (http://localhost:3000/).

$ yarn start # or npm start

Now I can browse the schema and test the queries!

GraphiQL with schema explorer in a browser

Example query with query variables in GraphiQL

GraphQL backend providers

Fri, 26 Jan 2018 05:48:07 GMT

There’s a list of GraphQL services on the official website of GraphQL. Most of these are backend as a service solutions. At first look, it might seem like a good idea to use them.

BaaS concept

In short, the backend as a service (BaaS) grants a cloud based backend for our mobile or web app - or for only some parts of them. This can be for example user management, social media integration or any function we have defined. Some providers let us create full-featured CRUD application backend using only their web graphical user interface.

We can use this backend through an API. If we have a CRUD app we can create, read, update and delete data via usual client-server communication.

The BaaS providers charge their customers for the service. This can be a monthly, annual or usage based fee.

Nowadays - as the market has expanded - basically everything is available through a BaaS. There are traditional REST API and GraphQL API providers. This article is about the latter ones.

Most of them has transformed or the development has stopped

This is the current list of BaaS services on the official GraphQL website:

~~GraphCMS~~ Hygraph
Graphcool
Reindex
Scaphold
Tipe (this one is marked as software as a service)

Probably the best-known of the services above is Graphcool. Their extremely ambitious team is in Berlin and they have acquired well deserved reputation in no time. The GraphQL backend can be defined through their well-designed web console without deep coding knowledge.

In October, 2017 they announced that they would change the business model of Graphcool and in the future it would be transformed to an open source backend framework. Although they are also keeping their existing BaaS, the web console with 3rd party integrations has noticeably taken a back seat.

Scaphold is very similar to Graphcool. There are more 3rd party provider integration options in their web console and it is possible to define custom interfaces for the schema. Nevertheless it is not hard to find bugs on this web interface, saving changes fails several times due to server error.

The Scaphold’s Slack is like a ghost town where a pinned message says:

IMPORTANT: We’re currently going through some product changes. Until further notice, we are under maintenance mode. We really appreciate your patience and support!

The founders (and owners?) are members of this Slack group, however they don’t respond to any questions and don’t try to dispel rumours that have been spreading around on Scaphold’s death. There are rumours about both acquisition and litigation. Anyhow, it seems risky to use Scaphold as BaaS for a new, greenfield project.

The url of the Reindex BaaS navigates to a 404 Not Found page. They announced in an article on their blog that because of the strong competition they are discontinuing the hosted service and they make the source code available under open source license. Unfortunately I did not have the opportunity to try the Reindex BaaS.

I haven’t tried ~~GraphCMS~~ Hygraph either. Those who tried recommend it: they say it has great support, an active developer team and they would like to work as BaaS provider in the future. Maybe I’ll write an article about my experience if I try it in the future. Until then good luck for them!

Tipe is in request access phase. Anyone can register and request an invitation to use their service. This email address collecting is a common practice, sometimes they do this when there is a business idea and they want to measure and predict how large the possible user base is. Then they can decide whether to start the business or not based on this result. I don’t say that Tipe works like this but I haven’t received the invitation I requested 2 months ago.

The question arises based on the above: why do these providers transform or discontinue their development?

It’s easy to reach their limits

The services I have tried mostly have the same functionality. Generally each software is similar in some aspects of development until a certain point. Data can be created, read, modified and deleted through an interface. Maybe some of these need user registration and different permissions.

After the _certain point _the business logic starts to get complicated, therefore the software needs more complicated and unique development solutions. Hence the need for custom backend functions. BaaS providers let their users define these functions in the web console.

However, if not just one developer but an entire team works on the project at the same time, they have to use the same console. This makes development more difficult as writing tests for the functions is not available (at least currently) and simultaneous editing can cause data (code) loss.

Likewise, version control is also missing, it’s hard to track what is changed, when and why and by whom.

For how long is it worth using them?

I think BaaS could save the time and cost of the backend development of a greenfield or prototype application. Thus, using a BaaS for a not too complicated MVP (Minimum Viable Product) application can be considered a good option.

Later, when we find out during the test phase of our MVP application that it has potential, and there’s a need to continue the development, it might be worth dedicating backend developers to the project. The GraphQL schema can be exported from both Graphcool and Scaphold, using them makes the backend development easier.

Foresight: Amazon appears on the stage

At the end of November 2017, Amazon announced that they would start their managed GraphQL service. AWS AppSync can be a huge competitor for most of the currently available BaaS providers. Mostly because Amazon has several experienced developers (the dev power) who can help the company to catch up with GraphQL. On the other hand, if the AppSync is integrated easily into the existing Amazon architecture, it can be a decision point for a developer team: using a well-known and already used provider instead of a smaller, startup-like BaaS.

Currently the AWS AppSync is in preview phase, to use it an invitation request needs to be submitted. So far I haven’t done that, as the request form asks for credit card data.

GraphQL backend szolgáltatók

Tue, 09 Jan 2018 05:51:07 GMT

A GraphQL hivatalos oldalán van egy lista a GrahpQL technológián alapuló szolgáltatókról. Ezek nagyrésze backend as a service (BaaS) megoldás. Első ránézésre remek ötlet ilyet használni.

BaaS koncepció

A backend as a service lényege, hogy a telefonon vagy böngészőben futó alkalmazáshoz tartozó backend-et - vagy annak bizonyos részeit - egy felhőalapú szolgáltató biztosítja. Ilyen lehet például a felhasználó-kezelés, integráció a közösségi médiával vagy bármi általunk definiált funkció. Néhány szolgáltató lehetőséget biztosít arra, hogy webes felületükön akár pár perc kattingatás után egy komplex CRUD alkalmazás backend-et kapjunk.

A backend-et az alkalmazásunkból egy API-n keresztül érjük el. Egy CRUD alkamazás esetén a szokásos kliens-szerver kommunikáció révén tudunk adatot létrehozni, lekérni, módosítani vagy törölni.

A BaaS szolgáltatók pénzt kérnek a szolgáltatásukért. Ez lehet havi vagy használat, forgalom alapú díj is.

A BaaS piac nagyra nőtt már, szinte mindenre létezik ilyen megoldás. Vannak tradícionális REST API-t biztosítók és GraphQL API-t biztosítók is, ebben a cikkben az utóbbiakkal foglalkozok.

A legtöbb fejlesztése leáll vagy átalakul

A GraphQL oldalán ma felsorolt BaaS szolgáltatók:

GraphCMS
Graphcool
Reindex
Scaphold
Tipe (ez igazából software as a service-nek van megjelölve)

Ezek közül talán a legismertebb a Graphcool. Roppant ambíciózus csapatuk Berlinben van, hamar nagy népszerűségre tettek szert, nem is véletlenül. Szépen megrajzolt weboldalon biztosítanak egy konzolt, melyben kódolási ismeretek nélkül létre lehet hozni egy GraphQL backended.

2017 októberében bejelentették, hogy üzleti modelljük átalakul és a továbbiakban backend framework-ként szeretnének tovább működni. Bár megtartják a BaaS szolgáltatást is - a korábbi, 3rd party szolgáltatás integrációkkal és webes szerkesztővel működő verzió érezhetően háttérbe szorult.

A Scaphold nagyon hasonlít a Graphcool-hoz. Webes felületükön valamivel több 3rd party szolgátató integrációjára adnak lehetőséget, illetve lehet egyéni interface-eket létrehozni a sémához. Viszont nem nehéz bug-ot találni ezen a webes felületen, többször valamiféle szerverhiba miatt sikertelen a mentés.

A Scaphold szellemvároshoz hasonlító Slack csoportjában kitűzött üzenet, hogy a szolgáltató nagy átalakításon megy keresztül, addig is “karbantartás módban” üzemelnek, kérik az ügyfelek szíves türelmét és megértését. Az alapítók, tulajdonosok - bár tagjai a Slack csoportnak -, nem válaszolnak a kérdésekre és nem is próbálják eloszlatni a pletykákat, miszerint a Scaphold meghal(t). A csoportban egyébként vannak pletykák felvásárlásról és perről is. Mindenesetre egy újonnan fejlesztett szoftverhez a Scaphold-ot választani BaaS-nek kockázatos vállalkozásnak bizonyul.

A Reindex BaaS-re mutató link 404 Not Found oldalra visz. A blogjukra térve van egy bejegyzés, mely szerint a BaaS-t - főleg az erős konkurencia miatt - leállítják, a kódbázisukat nyílt forráskódúvá alakítják, az eddigi támogatást köszönik. Sajnos a Reindex BaaS-et még ereje teljében nem sikerült kipróbálnom.

A GraphCMS-t sem próbáltam még ki. Akik kipróbálták, dicsérik: jó a támogatottsága, aktív fejlesztői csapat áll mögötte és továbbra is BaaS-ként szeretnének működni. Ha majd kipróbálom, lehet, hogy megírom a tapasztalatimat, addig is sok sikert nekik!

A Tipe ma még “request access” fázisban van, vagyis nem regisztrálhat akárki, fel kell iratkozni meghívóra. Bevett szokás egy ilyen feliratkozós rendszert már akkor közzétenni, amikor a szolgáltatás - amire fel lehet iratkozni - még csak fejben vagy papíron létezik. Így annak függvényében, hogy hányan iratkoznak fel - vagyis mennyien érdeklődnek - vágnak bele a fejlesztésbe vagy néznek új üzleti lehetőségek után. Persze egyáltalán nem biztos, hogy a Tipe is ezt játssza, mindenesetre eddig én nem kaptam meghívót, pedig kb 2 hónapja feliratkoztam rá.

A fent leírtak alapján felmerült bennem a kérdés, hogy miért tűnnek el vagy alakulnak át ezek a szolgáltatók?

Könnyű elérni ezek határát

Az általam kipróbált szolgáltatók többnyire ugyanazokat a lehetőségeket biztosítják a fejlesztők számára. A szoftverek egy bizonyos pontig nagyon hasonlítanak. Adatot lehet bennük létrehozni, megtekinteni, módosítani és törölni. Esetleg ezek regisztrációhoz vannak kötve és felhasználók különféle jogkörökkel rendelkeznek.

Egy pont után, ahol a program értelmét adó üzleti modell elkezd bonyolódni, ott következésképpen az alkalmazás is komplikáltabb fejlesztői megoldásokat igényel. Itt jönnek képbe jellemzően az egyéni backend függvények, melyekkel ez megvalósítható és erre a BaaS lehetőséget is ad a webes felületen keresztül.

Ha azonban nem csak egy fejlesztő, hanem egy csapat dolgozik ezen, akkor ugyanazt a felületet módosítanák többen - akár egyidőben is. Így a fejlesztők hamar egymás lábára léphetnek, főleg, hogy ezek a felületek nem adnak (ma még) lehetőséget, hogy ezekhez a függvényekhez tesztet írjunk.

Ugyanitt merül fel problémaként a verziókövetés hiánya: nehéz dokumentálni és visszakövetni, hogy melyik változás, mikor, ki által és miért következett be.

Akkor meddig jó?

Úgy gondolom, hogy egy zöldmezős vagy prototípus alkalmazás létrehozásakor sok, backend fejlesztésre szánt idő (és pénz) megspórolható a BaaS által. Egy nem túl komplex, MVP (Minimum Viable Product, minimum elvárásokat teljesítő termék) alkalmazáshoz jó választás lehet egy ilyen szolgáltatás használata.

Ha erről az MVP alkalmazásról a piacra kerülést követően vagy a tesztfázisban kiderül, hogy “van benne potenciál”, azaz van igény a továbbfejlesztésre, akkor érdemes lehet backend fejlesztőket dedikálni a projektre. A Graphcool és Scaphold felületén is van lehetőség kiexportálni a sémát, azok felhasználásával a saját backend fejlesztése már nem nulláról indul.

Előretekintés: az Amazon színrelép

November végén az Amazon bejelentette, hogy ők is “beszállnak a GraphQL-be”. AWS AppSync szolgáltatásuk konkurenciát jelenthet valamennyi jelenlegi GraphQL BaaS számára. Főleg azért, mert az Amazon-nál rengeteg a tapasztalt, jól képzett fejlesztő, akik segítségével igen hamar behozható a cég lemaradása a GraphQL területén. Másrészt, ha az AppSync integrálódik a meglévő Amazon szolgáltatásaikba, akkor ez is döntési pont lehet egy fejlesztőcsapat számára, hogy a már amúgy is használt és ismert szolgáltatót választják a kisebb, start-up hangulatú BaaS-ekkel szemben.

Az AWS AppSync jelenleg még kipróbálási szakaszban van, igényelni kell hozzáférést. Mivel ez a bankkártya adatok megadásával jár, én ezt egyelőre nem tettem meg.

Gitlab CI beállítás Rails projekthez

Tue, 03 May 2016 21:07:39 GMT

GitHub helyett a hobbiprojektekhez inkább a GitLab-ot használom. Többek között azért, mert ingyen lehet benne private repository-kat létrehozni (Github-on azt hiszem, 1 ilyen lehet ingyen). Másrészt számomra kényelmesebb a használata, a felülete jobban tetszik. Egyik újítás, hogy 2016. április közepe óta a GitLab összefogott a DigitalOcean-nal és lehetőséget adnak arra, hogy ingyenesen futtassunk job-okat a GitLab CI keretein belül.

A folyamat úgy néz ki, hogy GitLab-ra push-olt kód egy Runner-en lefut és a futás eredménye megjelenik a GitLab-on. A Runner-ek azok a környezet, melyeken a buildelés / futtatás történik. Ilyne Runner-t lehet futtatni egy helyi Docker konténerben is, de a DigitalOcean a nép rendelkezésére bocsát néhány úgynevezett “Shared Runner”-t, melyet lehet használni bátran.

Mire jó ez?

Automata tesztek futtatására
Deploy-álásra például sikeres futás esetén egy adott production környezetre
Kódminőség ellenőrzésre

A fentieken kívül és túl használható egyéb olyan építésekhez, melyeket úgy általában a CI rendszereken szoktak végezni. A példa projektben az automata tesztek futtatása és kódminőség ellenőrzése lesz történik a GitLab-on keresztül DigitalOcean Runner-ben.

Projekt részletek

Ruby 2.2.3-p173
Rails 4.2.6
JavaScript Runtime: Node.js (V8)
Database: PostgreSQL
Kódminőség ellenőrzés: Rubocop

CI konfigurálása

Először a projekt gyökérkönyvtárában létre kell hozni egy gitlab-ci konfigurációs fájlt: .gitlab-ci.yml

Ebben a fájlban definiáljuk, hogy miket szeretnénk futtatni milyen job-ok keretein belül.

image: ruby:2.2

services:
  - postgres:9.3

variables:
  # Configure postgres service (https://hub.docker.com/_/postgres/)
  POSTGRES_DB: custom_db
  POSTGRES_USER: custom_user
  POSTGRES_PASSWORD: custom_pass
  
before_script:
  - apt-get update -qq && apt-get install -y -qq nodejs
  - bundle install

test:
  script:
  - bundle exec rake db:drop RAILS_ENV=gitlabci
  - bundle exec rake db:create RAILS_ENV=gitlabci
  - bundle exec rake db:migrate RAILS_ENV=gitlabci
  - bundle exec rake test RAILS_ENV=gitlabci

rubocop:
  script:
  - bundle exec rubocop

Az image résznél definiáljuk, hogy milyen környezetben szeretnénk futtatni a job-okat. Ez job szinten is megadható, jelenesetben globálisan értendő. A services-en belül olyan szolgáltatást listázhatunk, melyet a futtatások során használni szeretnénk. Jelenleg ez egy postgres-t tartalmaz: ilyenkor egy postgres konténer is elindul, melynek a tesztadatbázisa a variables-ben megadott változókkal érhetők el. A before_script az összes job előtt lefut. A test és rubocop egy-egy job-ot jelöl, ez a nevük. Ezeken belül a script alatt kell definiálni az egyes lépéseket, melyek a job keretein belül futtatandók - ezek a parancssorban is megadható utasítások:

# JavaScript runtime telepítése
$ apt-get update -qq && apt-get install -y -qq nodejs
# projekt telepítése, szükséges dependenciák letöltése
$ bundle install
# korábbi custom_db tábla tartalmának eldobása
$ bundle exec rake db:drop RAILS_ENV=gitlabci
# tábla létrehozása újból és a szükséges migrációk futtatása
$ bundle exec rake db:create RAILS_ENV=gitlabci_ és _bundle exec rake db:migrate RAILS_ENV=gitlabci
# tesztek futtatása
$ bundle exec rake test RAILS_ENV=gitlabci
# kódminőség-ellenőrzés futtatása
$ bundle exec rubocop

CI-specifikus környezet definiálása

A fenti részben feltűnhet, hogy az egyes utasítások mögött szerepel a RAILS_ENV=gitlabci argumentum. Erre az adatbázis-kapcsolat és a környezettől függő Gemfile group miatt van szükség, mivel ugyanúgy szeretném megőrizni a fejlesztői környezethez és a helyi tesztfuttatáshoz használt, helyi Docker konténerben futó PostgreSQL beállításokat.

Új környezet létrehozásának lépései:

config/environments mappában test.rb duplikálása gitlabci.rb néven
config/database.yml fájlhoz gitlabci beállítások hozzáadása
Gemfile-ban csoportok frissítése

A .gitlab-ci.yml fájlban megadottaknak megfelelően a database.yml-ben a gitlabci beállítások:

gitlabci:
  adapter: postgresql
  encoding: unicode
  pool: 5
  host: postgres
  username: custom_user
  password: custom_pass
  database: custom_db

Esetemben a Gemfile-ben az alábbiak módosultak:

group :test, :gitlabci do
  # Mock API with webmock
  gem 'webmock'
  # Test framework
  gem 'rspec'
end

group :development, :gitlabci do
  # Static code analyzer
  gem 'rubocop', require: false
end

A webmock-ot és rspec-et csak a test és gitlabci környezeteken használom, mivel ezekben történik a tesztek futtatása. Ezzel szemben a rubocop-ot csak development és gitlabci környezeteken futtatom, így a test környezeten a bundle install idejét nem növelem feleslegesen ennek függőségnek a telepítésével.

Megjegyzés: másik elterjedt módszer, hogy egy másik, CI adatbázisadatokat leíró database.yml fájlt is létrehoznak, melyet copy paranccsal a CI környezetben aktiválnak oly módon, hogy felülírják vele az eredeti database.yml-t.

További információk, felhasznált irodalom:

Légkondi készítése házilag

Sun, 09 Aug 2015 10:28:59 GMT

Mikor nagyon melegem volt a lakásban, egyszer csak beírtam a Google-be, hogy “DIY air condition” és a találatok között erre alapozva én is elkészítettem a sajátomat.

Nem igazi hűtés ez.

Azért nem, mert a “hideg energiát” tároló jégakkut a lakásban lévő hűtőben “töltöm fel”. Így a hűtés során a hűtő hátul melegít - és a nem 100%-os hatásfok miatt még több energiát használ el a hűtés során, mint amennyit a jégakku nyer. Ezzel szemben a beszerelt légkondik a kinti egységük által az előállítás során a meleget a lakásból kifelé nyomják, a hideget pedig befelé. Akkor mire jó mégis ez? Lokális hűtésre, afféle “tűzoltásra”. A hűtő a lakás egyik pontján van, én pedig egy másik pontján ülök vagy fekszek. Ez a kis doboz szállítható, oda teszem, ahová épp a hűvös levegőt szeretném. Azért jobb, mint egy sima ventilátor, mert míg az a meleg levegőt keringeti, ez a jégakku által hűtött levegőt fújja.

Hozzávalók:

Hungarocell doboz
Processzor hűtő (pl egy régóta használaton kívüli)
Telefontöltő (régi telefoné vagy olyan, aminek a telefon felőli csatlakozója sérült)
Jégakku vagy jégkocka

Elkészítés:

Első lépésként nézzük meg, hogy működik-e a ventilátor az adapterrel. Én egy régi, 12V-os Intel hűtőt találtam, meg egy utángyártott, kontakt hibás 5V-os telefontöltőt. A töltőről a microUSB csatlakozót levágva hozzáérintettem a CPU csatlakozásához és pörög is. Nyilván lassabban, de átmeneti megoldásnak jó lesz.

Tervezzük meg, hogy hová vágjuk a lyukakat. Én a doboz tetejére vágtam a ventilátornak nyílást, a doboz oldalára pedig a kiáramló levegőnek. A ventilátor helyét egyszerűen úgy jelöltem, hogy rátettem és filctollal körberajzoltam. A lehetőségekhez mérten érdemes inkább belső íven rajzolni, mert a vágás során 1-2 mm vastagságú vágás során nagyobb lehet a lyuk, mint tervezzük. Ilyenkor a ventilátor beleesik a dobozba, az pedig úgy nem hatékony.

A doboz oldalára a lyukat körzőbe befogott filctollal rajzoltam, de egy pénzérme vagy pohár körberajzolása által is elérhető ugyanaz az eredmény. Láttam olyat, hogy kályhacső könyökidomot épített be valaki egy ilyenbe. Eredetileg én is terveztem, de túl drágának és nagynak találtam azokat ahhoz a dobozhoz, amit én használok, így beérem sima lyukakkal.

A vágást legtöbbször késsel vagy fűrészlappal csinálják, engem ennek a hangjától a hideg ráz. Édesapám javaslatára egy felforrósított szeggel oldottam ezt meg. Úgy szalad a hungarocellben a forró szeg, mint a meleg kés a vajban. Gyorsan és szépen lehet így alakzatokat kivágni.

Annyit tettem még, hogy a telefontöltő levágott végén a rézszálakat bevontam ónnal egy forrasztópáka segítségével, hogy könnyebben bedughassam a CPU ventilátor hűtőjébe. Akár le is lehet vágni a CPU hűtő csatlakozóját és hozzáforrasztani a tápvezetéket. Én ezt azért nem tettem meg, mert egyrészt így a CPU hűtő bármikor visszaszerelhető egy PC-be - bár nem hiszem, hogy erre sor kerül valaha is -, másrészt tervezem egy 12V-os adapter beszerzését, amivel majd gyorsabban pöröghet a ventilátor.

A “rendszer” skálázható, mehet bele több jég vagy jégakku, lehet befogni több ventilátort, vágni több lyukat a kiáramló levegőnek. Nekem a következő lépésben annyi a tervem, hogy az adaptert 12V-osra cserélem és szabályozhatóvá teszem a fordulatot.

Eredmény:

Bemegy a meleg, kijön a hideg.

Rails lista/grid nézet kapcsolás

Thu, 14 May 2015 21:05:33 GMT

Hasznos és gyakori az olyan kapcsolók használata a weboldalakon, melyekkel egy lista nézetét lehet állítani. Találtam egy egyszerű és gyors módot arra, hogy miképp lehet ezt egyszerűen kivitelezni Rails-ben.

A példában egy videóadatbázis nézeteit lehet állítani: listanézetben a “hagyományos” generált scaffold elrendezés látható, grid nézetben pedig mondjuk csak a film borítóképe, címe, kategóriája és játékideje látszik, responsive módon.

Hozzávalók:

Controller (app/controllers/videos_controller.rb)
Index view (app/views/videos/index.html.erb)
Partial-ok a nézetekhez (app/views/videos/_grid_view.html.erb és app/views/videos/_list_view.html.erb)

Először készítsük el a partial-okat. Ezek a ”_“-al kezdődő fájlok, amiket <%= render "név" %> módon illeszthetünk a view-ba.

app/views/videos/_grid_view.html.erb

<% @videos.each do |video| %>
  <div class="col-md-6 col-lg-4 col-xl-3">
    <div class="row extra-space-between-rows">
      <div class="col-md-4 col-lg-4">
        <%= image_tag("http://placekitten.com/140/140", :size => "135x135", :class => "img-rounded img-responsive") %>
      </div>
      <div class="col-md-8 col-lg-8">
        <h5><%= link_to video.title, video%></h5>
        <i><%= video.subject.name %></i><br>
        <strong>Release date: </strong><i><%= video.release_date.strftime("%Y. %m. %d.") %></i><br>
        <strong>Length: </strong><i><%= video.length.strftime("%H hours %M minutes") %></i><br>

        <%= link_to 'Edit', edit_video_path(video), :class => "btn-xs btn-info" %>
        <%= link_to 'Destroy', video, method: :delete, data: { confirm: 'Are you sure?' }, :class => "btn-xs btn-danger" %>
      </div>
    </div>
  </div>
<% end %>

app/views/videos/_list_view.html.erb

<table>
  <thead>
  <tr>
    <th>Title</th>
    <th>Company</th>
    <th>Release date</th>
    <th>Length</th>
    <th>Description</th>
    <th>Subject</th>
    <th colspan="3"></th>
  </tr>
  </thead>

  <tbody>
  <% @videos.each do |video| %>
    <tr>
      <td><%= video.title %></td>
      <td><%= video.company_id %></td>
      <td><%= video.release_date %></td>
      <td><%= video.length %></td>
      <td><%= video.description %></td>
      <td><%= video.subject_id %></td>
      <td><%= link_to 'Show', video %></td>
      <td><%= link_to 'Edit', edit_video_path(video) %></td>
      <td><%= link_to 'Destroy', video, method: :delete, data: { confirm: 'Are you sure?' } %></td>
    </tr>
  <% end %>
  </tbody>
</table>

Következő lépésben a controller-t felkészítjük arra, hogy mi nézetet váltunk néha. Ehhez bevezetünk egy új paramétert. Az ”||” után pedig a default értéket adjuk meg (ha esetleg nem lenne paraméter, akkor se dőljön össze a rendszer). (app/controllers/videos_controller.rb)

def index
  @videos = Video.all
  @partial = params[:view] || "grid_view"
end

Végül az index.html.erb-ban végzünk pár módosítást. Betesszük a kívánt helyre a renderelést:

<div class="row">
  <%= render @partial %>
</div>

És a linkeket vagy button-okat, amikkel állítjuk a nézetet.

<div class="btn-group" role="group">
  <button type="button" class="btn btn-default dropdown-toggle" data-toggle="dropdown" aria-expanded="false">
    View
    <span class="caret"></span>
  </button>
  <ul class="dropdown-menu" role="menu">
    <li><%= link_to "Grid", videos_path(view: "grid_view") %></li>
    <li><%= link_to "List", videos_path(view: "list_view") %></li>
  </ul>
</div>

Lapozás Rails-ben Kaminari-val

Sun, 12 Apr 2015 10:17:34 GMT

Ha egy lista túl sok elemet tartalmaz, érdemes lapozással kisebb szeletekre vágni a megjelenített tartalmat. Ennek több előnye is van, például: kicsit kímélhetjük az adatbázist, rövidíthetjük az oldalbetöltés idejét, stb. A kaminari gem lehetővé teszi, hogy ezt roppant egyszerűen megoldjuk.

Adjuk hát hozzá a Rails projektünk Gemfile-jához a kaminarit, majd telepítsük is azt bundler-rel.

gem 'kaminari'

bundle install

Generáljuk a szükséges konfigurációs fájlokat:

rails generate kaminari:config

Állítsuk be az alapértelmezett oldalméretet abban a model-ben, aminek a elemeit listázzuk. Ha például egy blog post-jait szeretnénk oldalanként megjeleníteni, akkor az app/models/post.rb-ba írjuk bele ezt:

paginates_per 10

Ez elintézi nekünk, hogy oldalanként 10 post jelenjen meg. (Persze ha 15-öt szeretnénk oldalanként, akkor 10 helyett 15-öt kell írnunk).

Következő lépésként a controller-ben kell módosítanunk a listázást. Ez esetünkben az app/controller/posts_controller.rb fájl, melynek az index method-ját módosítjuk:

# Ezt egészítsük ki
def index
  @posts = Post.all
end

# Erre
def index
  @posts = Post.order(:created_at).page(params[:page])
end

Végül a view-ban jelenítsük meg a lapozót, ahol szeretnénk. Ezt a példában az app/views/posts/index.html.erb fájlban az alábbi módon tehetjük meg:

<%= paginate @posts %>

Ezzel meg is volnánk, az oldalon megjelenik a lapozó!

Részletesebb leírás és sok példa elérhető Github-on: amatsuda/kaminari

Keresőbarát URL-ek Rails-ben

Wed, 18 Mar 2015 21:47:42 GMT

Van egy nagyon tuti gem, ami hozzásegít ahhoz, hogy az URL-ben számok helyett szöveg jelenjen meg. Például: www.example.com/posts/2 helyett www.example.com/posts/super-post. Ez azért is jó, mert a keresők jobban szeretik az ilyet - így akár előrébb is kerülhet az oldal a találati listákban. Másrészt, ha könyvjelzőkhöz adja egy felhasználó, vagy bemásolja valahová (például e-mailbe) a címet, akkor sokkal beszédesebb az URL-ben a bejegyzés címe, mintha csak egy ID-t tartalmazna.

A gem neve friendly_id. A dokumentációja itt található, a github oldala pedig itt.

A parancssorba/terminálba beírva telepíthetjük a legfrissebb verziót. Rails 4-hez legalább 5.0.0 kell. Nekem ma 5.1.0-t telepített. Pipa.

gem install friendly_id

Telepítés után adjuk hozzá az aktuális projektünk Gemfile-jához a friendly_id-t:

gem 'friendly_id'

Majd futtassunk parancssorban egy bundle-t, hogy települjön szépen:

bundle install

Következő lépésként a már meglévő táblánkhoz - amelyikből jelenleg ID-t mutatunk URL-ben - adjunk hozzá egy új oszlopot. Ezt - ahogy korábban bővebben leírtam - az alábbi módon tehetjük meg:

rails generate migration add_slug_to_posts slug:string

Hajtsuk végre a migrációt, parancssorba írjuk:

rake db:migrate

Ezután a model-ben kell megadnunk, hogy melyik oszlop tartalma jelenjen meg ID helyett az URL-ben. Jelenlegi példában a bejegyzés címét (title) adjuk meg (app/models/post.rb):

  extend FriendlyId
  friendly_id :title, use: :slugged

Így már az újonnan létrehozott bejegyzéseknek az URL-jében a cím jelenik meg. Ahhoz, hogy ezt meg is tudjuk nyitni, szükséges némiképp módosítani is az app/controllers/posts_controller.rb-t. A private method-ok között módosítanunk kell, hogy ne közvetlenül használja a title-t ID-ként, mert úgy sosem találja meg.

  # ezt egészítsük ki:
  @post = Post.find(params[:id])
  
  # erre:
  @post = Post.friendly.find(params[:id])

Figyelni érdemes arra is, hogy akár több bejegyzés is lehet azonos címmel. Ennek kezelése érdekében kapcsoljuk be a history-t a slug-okra. Ehhez annyi kell, hogy generálunk egy új migrációt és futtatjuk:

rails generate friendly_id
rake db:migrate

Bónusz: amennyiben vannak már korábbi bejegyzéseink, melyeknek az URL-je még nem szép, akkor rails console-ban átalakíthatjuk őket. Lépjünk be tehát a konzolba:

rails console

És frissítsük a bejegyzéseket:

  irb(main):001:0> Post.find_each(&:save)

Autentikáció Rails-ben Devise gem-mel

Mon, 16 Mar 2015 20:53:24 GMT

A Devise gem lehetőséget nyújt arra, hogy Rails alkalmazásunk bizonyos funkció egyszerűen és profin védve legyenek - csak regisztrációt és bejelentkezést követően legyenek elérhetők.

Telepítés

Hozzáadjuk a Gemfile-hoz a Devise-t:

gem 'devise'

Futtatunk egy bundle telepítést parancssorban:

bundle install

Generálunk egy alap konfigurációt az alkalmazáshoz:

rails generate devise:install

Következő lépésként létrehozzuk a User model-t:

rails generate devise user

Ez a config/routes.rb fájlba is beírja, hogy van ilyen devise dolog.

Védelem a controller-ben

Következő lépésként beállíthatjuk, hogy melyik controller-nek melyik method-jait akarjuk autentikációhoz kötni. Íme egy példa (app/controllers/testcases_controller.rb)

before_filter :authenticate_user!, only: [:new, :edit, :create, :update, :destroy]

A fenti példában a szögletes zárójelben felsoroltak lesznek bejelentkezéshez kötve. Tehát a _CRUD-_ból (Create Read Update Destroy) az R kivételével minden (tehát csak megtekinteni lehet anélkül, hogy bejelentkeznénk).

Védelem a view-ban

A view-okban is beállíthatjuk, hogy egyes elemek csak akkor jelenjenek meg, ha bejelentkezett a kedves felhasználó. Például az app/views/testcases/index.html.erb fájlban:

<% if user_signed_in? %>
  <%= link_to 'Edit', edit_testcase_path(testcase)  %>
  <%= link_to 'Delete', testcase, method: :delete, data: { confirm: 'Are you sure?' } %>
<% end %>

Így a szerkesztés és törlés gombok bejelentkezés nélkül nem is lesznek láthatóak.

További információ a Devise-ról

Getting started GitHub-on: https://github.com/plataformatec/devise#getting-started

Rubydoc dokumentáció: http://www.rubydoc.info/github/plataformatec/devise/

Oszlop hozzáadása táblához vagy oszlop törlése táblából Rails-ben

Sat, 14 Mar 2015 20:24:41 GMT

Gyakran járok úgy, hogy utólag hozzá kell adni egy Rails alkalmazás adatbázisának valamelyik táblájához még egy oszlopot - vagy módosítani, törölni kell egy már meglévőt. Lássuk, mik a lehetőségek.

A Rails alkalmazás mappájába navigálva parancssorba írom ezt:

rails generate migration add_coolfields_to_tablename fieldname:string otherfield:string

Az add_ utáni szó (fenti példában _coolfields_)a migration-t nevezi el tapasztalatom szerint, túl sok jelentősége nincs . A _to_ utána szó (fenti példában _tablename_) viszont fontos, ez a tábla neve, ahová injektálni szeretnénk.

Itt egy konkrétabb példa:

rails generate migration add_contact_details_to_customers work_email:string private_email:string

CamelCase-t is használhatunk:

rails generate migration AddContactDetailsToCustomers work_email:string private_email:string

Ennek hatására a projekt db/migrate mappájában születik egy új fájl [dátumidő]_addfieldname_to_tablename.rb néven. Azt, hogy eddig milyen nevű és típusú oszlopok vannak a táblában, azt a db/schema.rb fájlból szoktam kihalászni. Ott látszik, hogy a táblák neve többesszámban van, így emlékeztet arra, hogy a migráció létrehozásakor is azt használjak.

Az oszlop törlése hasonlóképp működik, ott ez a varázsige:

rails generate migration RemovePhoneFromCustomers phone:string

Hogy az elvégzett módosítás életbe lépjen, szükséges egy migrációt futtatni az adatbázison, erre jó a következő parancs:

rake db:migrate

Vagy ha mondjuk csak a TEST környezethez belőtt adatbázison szeretnénk először:

rake db:migrate RAILS_ENV=test

Bővebb infó: http://edgeguides.rubyonrails.org/active_record_migrations.html

Ruby on Rails telepítése Windows 8-ra

Wed, 01 May 2013 10:24:07 GMT

Az Interneten hozzáférhető tutorial-ok alapján úgy tűnik, hogy Ruby on Rails alapú honlapokat kevesen fejlesztenek Windows rendszereken. Bár én is használok Ubuntu-t is, jobban szeretem a Windows-t. Elhatároztam, hogy feltelepítem most legfrissebb Ruby-t, Gem-t, Rails-t és hozzá MySQL-t a 64 bites Windows 8 rendszeremre. Mivel természetesen nem úsztam meg hibaüzenet nélkül, szükségesnek éreztem, hogy dokumentáljam az eseményt, hogy legközelebb ne kelljen annyit keresgélni a probléma oka és megoldása után.

1. lépés: Ruby telepítése

Windows-ra ez egész könnyen megy, a http://rubyinstaller.org/ website letöltés oldaláról kiválasztottam a Ruby 2.0.0-p0 (x64)-t letöltöttem, majd gyakorlatilag “Next, Next, Next” módszerrel telepítettem, annyi a különbség, hogy a telepítés helyének kiválasztásánál kipipáltam, hogy rendelje a hozzá a .rb és .rbw fájlokat és hogy adja hozzá a Ruby-t a “PATH”-hoz.

Telepítés után parancssorba beírva a ruby -v parancsot látható, hogy sikeres volt-e a telepítés, ugyanis ha igen, a telepített Ruby verziószámát kapjuk eredményül.

2. lépés: RubyGems telepítése

Ez a csomagkezelő, amit a Ruby használ. A Ruby-val együtt ez is fel lett telepítve, így ezt nem kell külön telepíteni. Egy frissítést érdemes ellenőrizni parancssorban: gem update —system

Ha mégsem lenne telepítve valamiért, akkor a rubygems.org honlapról letölthető.

3. lépés: Rails telepítése

Mivel ez is egy gem, ezért telepítése egyszerűen, parancssorból történik: gem install rails

Miután telepítettük, jócskán megnő a telepített gem-ek listája: gem list paranccsal ellenőrizhetjük, hogy ott van-e a Rails.

4. lépés: MySQL telepítése

Ezzel volt a legtöbb gond, de a végén jó lett.

Először telepíteni kellett a MySQL Community Server-t, amit érdemes az .msi kiterjesztésű telepítővel végezni, ami elérhető: http://dev.mysql.com/downloads/installer/

A telepítés során elég kiválasztani, hogy csak a Server-t telepítse, a többire nincs szükség most.

Ezt követően a Ruby-hoz kell kapcsolni. Ehhez le kell tölteni egy C Connector-t a MySQL honlapjáról, nekem a mysql-connector-c-noinstall-6.0.2-winx64.zip működött végül. Ezt ki kell csomagolni, majd parancssorba ezeket a sorokat írni:

gem install mysql2 --platform=ruby -- --with-mysql-include=D:\mysql-connector-c-noinstall-6.0.2-winx64\include --with-mysql-lib=D:\mysql-connector-c-noinstall-6.0.2-winx64\lib --with-mysql-dir=D:\mysql-connector-c-noinstall-6.0.2-winx64

A Connectort én a D: meghajtómra csomagoltam ki, így az elérési út nálam “D:\mysql-connector-c-noinstall-6.0.2-winx64”.

Ha ERROR: Failed to build gem native extension.-t kapunk érdemes kipróbálni a 32 bites C Connector-t, van akinek azzal működik.

Így más sikeresen összeállt a kép és a rendszer, lehet Windows 8-on is készíteni RoR rendszereket.

12 reggeli dolog

Tue, 14 Aug 2012 20:08:53 GMT

Egy érdekes kutatás eredményét tette közzé a Business Insider. Több, mint 700 főt (17 és 79 év közötti embereket) kérdeztek meg az egészségi-, érzelmi állapotukról és arról, hogy melyik napszakot kedvelik. Kiderült, hogy a koránkelők vidámabbak, egészségesebbek és hatékonyabban dolgoznak, mint azok, akik “éjjeli baglyok” - vagyis az éjjel egy részét ébren töltik és inkább reggel alszanak tovább.

A felmérés eredményeként 12 pontba gyűjtötték össze azokat a tevékenységeket, amelyet a sikeres emberek reggelente elvégeznek. Ezek a következők:

Mindig már előző nap elkészítik a következő napi teendők listáját
Egész éjszaka alszanak
Nem nyomogatják a “szundi” gombot
Végeznek valamilyen testmozgást reggelente
Rutinszerűen végzik a reggeli dolgaikat
Reggeliznek
Időben bemennek a munkahelyre
Jelentkeznek a főnöküknél vagy a munkavállalóiknál (napi feladatok miatt)
A nagy feladatokkal kezdenek először
Kerülik a megbeszélések reggelre történő időzítését
Szakítanak időt az levelek/üzenetek nyomon követésére
Tartanak délelőtti szünetet

Az eredeti szöveg a U.S. News & World Report tulajdona. A fenti fordítás nem teljes, a listából csak a címmondatokat emeltem át, a rövid magyarázatokat nem. Akit érdekelnek fenti pontok bővebben kifejtve, a Business Insider honlapján eredeti nyelven megtalálja. Az esetleges fordítási hibákért felelősséget nem vállalok.

Társasházi számladíj-csökkentés odafigyeléssel 2. rész

Sun, 13 May 2012 17:33:37 GMT

Az előző rész tartalmából:

Lakásomban egy év alatt a gázszámla 5752 Ft-ról 4952-re, a villanyszámla 4136 Ft-ról 3715-re csökkent. A vízfogyasztás is mérséklődött 10%-al.

Villanyáram

Az elektromos áramot az ELMŰ szolgáltatja 38.191 Ft/kWh áron (ebbe már beleszámoltam a rendszerhasználati alapdíjat is). Az optimalizáláshoz és méréshez egy boltban vásárolt fogyasztásmérőt használok. Ez mutatja a pillanatnyi- és az időszaki fogyasztást, illetve ha be van programozva, akkor az elhasznált áram árát is.

Ezen a területen tudok a leghatékonyabban spórolni, bár a fogyasztásom nem szembetűnően kevesebb a nővéreméhez képest. Ez azért van, mivel többet vagyok otthon, és ilyenkor mindig van használatban néhány elektromos eszköz. Ilyen például a laptop, amihez kiterjesztésként egy 24”-os LED-es monitor van kötve, valamint az internethozzáférést biztosító router és modem. Ez utóbbi kettőt már nővérem is használta, azonban én - vele ellentétben - ha elmegyek otthonról, akkor egy billenőkapcsolóval leáramtalanítom a routert és modemet. Ezek nem nagy fogyasztású eszközök, a kettő együtt 12 W. Ez 0.458 Ft-ba kerül óránként. Egy nap átlagosan 12 órán át van áram alatt ez a két eszköz. Éves szinten számolva (0.458 (Ft) *12 (óra) *365 (nap)) legalább 2000 Ft-ot spórolok meg azzal, hogy leáramtalanítom ezt a két eszközt. Hasonló a helyzet a DVD lejátszó, TV és Hi-Fi esetében. Ez a 3 berendezés is egy billenőkapcsolós elosztóra van kötve, így csak akkor világít rajtuk a készenléti jel, ha a kapcsolót felkapcsolom. Ezeket az eszközöket naponta maximum 1 órát használom, így 23 órán át ki vannak kapcsolva. Mérésem szerint a készenléti állapotot visszajelző LED-ek és kijelzők a készülék kikapcsolt állapotában is összegezve 8W-ot fogyasztanak, ez óránként 0.305 Ft-ba kerül. Az előbbi számítási metódussal könnyen belátható, hogy a kapcsolgatásnak köszönhetően (0.305 (Ft) * 23 (óra) * 365 (nap)) kb. 2500 Ft-tal több marad a zsebben évente.

IT és média

Egyetemistaként és informatikusként sok időt kell a számítógép előtt töltenem. Híreket, leveleket olvasok, kapcsolatot tartok ismerősökkel, barátokkal, zenét hallgatok, weblapokat készítek, stb. Tehát nekem a laptop a munka és a szórakozás eszköze is. A laptop magában 80W-ot fogyaszt monitorral együtt, tehát energiatakarékosabb egy asztali PC-nél, ami esetében csak az alapgép 100-110W-ot fogyaszt (aktív használat esetén pedig ennél sokkal többet). Mivel a laptopom már elég régi darab és állandóan sok szolgáltatás fut rajta, így elég sokáig tart, míg bekapcsolás után használhatóvá válik a rendszer. Ennek gyorsítása végett jó ideje nem használom a “kikapcsolás” menüpontot, helyette a “hibernálást” választom. Ekkor a memória aktuális tartalma a merevlemezre íródik, és a gép kikapcsol. Bekapcsoláskor a merevlemezről minden visszakerül a memóriába, és onnan folytatódhat minden munka, ahol a hibernálás történt. Ezzel alkalmanként legalább 3-5 percet spórolok.

Az sem véletlen, hogy 2 monitort használok. Többek - például a BME Távközlési és Médiainformatikai Tanszék szerint is a több monitor használata növeli a hatékonyságot (10-42%-al), csökkenti a hibák számát, segíti a párhuzamos tevékenységeket, az adatok átvitelét alkalmazások között és a párhuzamos kommunikációt, valamint lényegesen megkönnyíti az összehasonlításokat. A BenQ G2420HDBL típusú LED monitor energiafelhasználását 36%-al csökkentették (a hagyományos LCD monitorokkal szemben), így a fogyasztása 24W. Ez a többlet viszont szükséges és meg is térül, ugyanis a grafikai munkákhoz és a nagy táblázatok kezeléséhez ez elengedhetetlen. Ha a laptopot bekapcsolva hagyom, de a monitort nem szükséges működtetni, akkor azt ki is kapcsolom. Mivel LED-es, nem árt neki, ha csak 2 percre kapcsolom ki.

Az egyetemen legtöbbször az oktató által kiadott jegyzetből kell tanulni. Ezek Interneten keresztül pdf formátumban érhetők el. Tantárgyanként általában 1 dolgozat megírásához 30-60 oldalas jegyzetek áttanulmányozása szükséges. Ezt kinyomtatni - az olcsónak számító, BME Copy 5 Ft/oldal árával számolva - 150-300 Ft zh-nként. Éjszakai tanulás esetén ehhez még hozzájön a 40W-os olvasólámpa költsége. Ráadásul ezek a jegyzetek csak pár napig “hasznosak”, utána a polcra kerülnek (vagy a kukába), ami pazarlás. Megoldás lehetne a jegyzetek továbbadása a következő évfolyamnak, de ez azért nem működik, mert egyrészt legtöbben tanulás közben összefirkálják a jegyzetet szövegkiemelőkkel és megjegyzésekkel, ami más számára lehet, hogy nem logikus. Másrészt, úgy gondolhatják, hogy még kellhet a jegyzet, esetleg lehet olyan indok is, hogy “ha ők kinyomtatták, nyomtassa ki más is”. Ráadásul a jegyzetekben lehetnek kisebb-nagyobb változtatások is évente. A fentiek tükrében hatékonyabbnak vélem, ha monitorról vagy tabletPC-ről tanulok. A monitor előnye, hogy egyszerre nagy felületet látok, így több slide-ot vagy oldalt is nézhetek egyszerre. Viszont ez óránként kb. 80W (laptop + monitor). Másik megoldás a tabletPC, amire akármennyi jegyzetet rátölthetek, bármikor és bárhol elérem azokat. LED-es érintőkijelzője van, melynek fényerejét szenzorok segítségével automatikusan a szemnek legoptimálisabbra szabályozza. Így tanulhatok ágyban, vonaton, vagy íróasztalnál is anélkül, hogy magammal hordanék sok-sok “egyszer használatos” papíralapú jegyzetet vagy könyvet. A tabletPC-m egy Motorola Xoom 3G. Egy töltéssel kevés használat mellett, készenlétben több mint 8 napig működik. Aktív használat mellett a kijelző kb. 10 órán át képes világítani. A töltő kimeneti feszültsége 12V, az áramerősség 1.5A. Innen számolható a teljesítmény, ami e két érték szorzata, azaz 18W. A teljes töltési idő (0-ról 100%-ra) 2 óra, azaz 1 feltöltés áramdíja 1.35 Ft (ennyibe kerül 10 óra aktív használat). Összehasonlítva ezt az olvasólámpa óránként elhasznált áramával látható, hogy a tabletPC-használat 1 órára (1.53/0.135) = 11-ed annyiba kerül, mint az olvasólámpa.

Nővérem minden este bekapcsolta a tv-t 2-3 órára. Nálam hetente megy maximum 2-3 órát a tv - vizsgaidőszakban vagy sok zárthelyi idején pedig annyit sem. Régi típusú, katódsugárcsöves Orion tv van, aminek a fogyasztása elég nagy, de nem ezért nem nézek tv-t, hanem mert nem érdekel. Amikor bekapcsolom, akkor is csak 1-1 DVD filmet nézek.

Világítás

A lakásban a fürdőszobai lámpákat és 2 olvasólámpát kivéve, mindenhol energiatakarékos izzó van. A fürdőszobában 2 db 50W-os izzó van. Alternatívaként még a LED-es lámpa jöhetne szóba, de annak fényereje jóval kisebb, ára pedig sokkal magasabb - nagyon soká térülne meg. Ahhoz itt kicsi a foglalat, hogy energiatakarékos izzót lehessen betenni, ráadásul ez tipikusan az a hely, ahová nem is érdemes. Ablaka nincs, így alapesetben állandóan sötét van és leggyakrabban 1-1 kézmosás, vagy zuhanyzás erejéig vagyok bent, illetve míg elindítom a mosógépet vagy kipakolok belőle. Ezek közül egyik sem több 5-10 percnél. Ez idő alatt egy energiatakarékos izzó még talán épp elérné a teljes fényerejét, már le is lenne kapcsolva, így az élettartama lényegesen csökkenne. Az energiatakarékos izzók hátránya, hogy hidegfényűek. Szemmel láthatóan fehér fényt bocsátanak ki, míg a hagyományos izzók sárgát. Ez utóbbi pihentetőbb a szemnek és kevésbé okoz stresszt. Ez az oka annak, hogy az olvasólámpákban a régebbi típusú izzó maradt. A szobai csillárban lévő energiatakarékos izzók fehér fénye sárgának tűnik, mivel a fal is sárga.

Az olvasólámpára szinte csak a feladatmegoldások gyakorlásánál van szükség. Ez azonban néha több órát vesz igénybe. Mivel azonban az íróasztalt az ablak mellé tettem, így csak esti/éjszakai gyakorlásnál szükséges a lámpát felkapcsolni, nappal elég az ablakon beszűrődő természetes fény. Ebben 40W-os izzó van, ami óránként 1.53 Ft-ért világít.

A konyhában is energiatakarékos izzó van a csillárban, de a szekrényekre még LIDL-ben vett elemes, öntapadós LED lámpákat ragasztottam. Ezek fénye nem nagy ugyan, de ha este kimegyek egy pohár vízért, akkor ahhoz elég fényt ad, nem kell emiatt fél percre felkapcsolni a nagylámpát. 6 db ilyen lámpám van mind a két faliszekrény alján 3-3, így azok még esztétikailag is jól mutatnak. Egyelőre csak külön-külön kapcsolhatók, de tervezem, hogy összekötöm őket, hogy egy kapcsolóval egyszerre fel lehessen őket kapcsolni. Ezekből 3 db került 1000 Ft-ba elemmel együtt. Egy éve vettem őket, azóta nem kellett elemet cserélni egyikben sem és fényerejükből sem veszítettek.

Konyha

Reggelente főzök egy kancsó teát és egy adag kávét. Van külön elektromos kávé- és teafőzőm is. Igaz, ezek az eszközök pörgetik kicsit a villanyórát, de ha kiszámolva a költségeket úgy látszik, így sokkal jobban megéri, mintha automatából, vagy büféből vennék. Nővérem ott tartózkodása alatt mindig forró vizet öntött a teafőző tartályába, mivel úgy gondolta, hogy akkor nem kell annyit melegítenie a teafőzőnek és gyorsabban, illetve kevesebb árammal lefő a tea. Lemértem hideg és forró vízzel egyaránt az időt és az áramfelvételt. Különbség nem volt, mind a két érték ugyanannyi lett mind a két esetben, így “olcsóbb” hideg vizet tölteni a tartályba. Egy tea lefőzése 0.15 kW áramot igényel, míg a kávéfőző csak 0.02 kW-t. 1 doboz Teekanne teafiltert (ami szerintem közepes minőségűnek mondható) 300 Ft-ért szoktam venni, ennyiből 20 adag főzhető (15 Ft/db). Az áramdíj ~5.73 Ft. Ehhez hozzáadódik az 1.2 liter hideg víz, amiből főzök és az a pár dl, amivel utána elmosom a kancsót. Így az áram + teafű + vízdíj együttesen nem haladja meg a 25 Ft-ot és kapok érte 1.2 l teát. Az édesítőt nem számoltam, ebből 9 db-ot teszek a kancsóba. Az ára 1200 db-os kiszerelésben max. 500 Ft, így ez még alkalmanként +3.75 Ft. A teafőző értékcsökkenését nem kalkuláltam bele az árba, de ez sem rontaná nagymértékben a végösszeget, mivel ez az eszköz legalább 4 éves és az ára még 4000 Ft sem volt. Napi használat mellett is hibátlanul működik.

A kávéfőzés esetében a 250g Omnia őrölt kávé 800 Ft-ért megvehető, ebből - adagonként 8g kávéval számolva - körülbelül 31 adag főzhető. Az anyagár tehát 25.6 Ft. Az elhasznált 0.02 kW ára 0.77 Ft, a minimális kakaó és 1 db kockacukor együtt max 3 Ft (kockacukor: 6g = 1.8 Ft, mivel 1 kg cukor 300 Ft). Tehát az otthon főzött, friss kávé is sokkal olcsóbb, mintha automatából venném.

A lakás egyik nagyfogyasztó berendezése a hűtő. Nem régi, “A” energiaosztályú Indesit. Nincs vele minden rendben, néha kicsit jobban hűt a kelleténél. A fagyasztó belső falán gyakran vastagon áll a hó és jég. Ezzel az a baj, hogy a belső falhoz hozzátapadva azt leszigeteli és a fagyasztó érzékelője nem tudja a benti levegő hőmérsékletét mérni, így még jobban fagyaszt, ami hatására a villanyóra csak pörög, a jégdarabok pedig nőnek. Hogy ezt a rekurzív folyamatot megállítsam (vagy legalább tompítsam), gyakran kikaparom a jeget a fagyasztó faláról. Így ez a berendezés is kevesebbet fogyaszt, mint korábban.

Fürdőszoba

A korábban említett 2 db 50W-os izzó óránként 0.1 kWh-t fogyaszt. Ez percenként 0.0636 Ft-ot jelent. A fogkefém elektromos, egy töltéssel 5-6 alkalommal tudom használni. A töltő 3W-ot fogyaszt óránként és a teljes töltési idő 3 óra. Ezekből az adatokból kiszámoltam, hogy maximum 0.0686 Ft-ba kerül percenként az elektromos fogkefe használata. A fogaszat.org információi szerint - és saját tapasztalat alapján is - az elektromos fogkefék számos előnye közül az egyik az, hogy a lepedéket gyorsabban és hatékonyabban távolítja el, mint hagyományosak - tehát hamarabb végzek. Így gyakorlatilag, amit nyerek a vámon, elvesztem a réven - és fordítva: a fogkefe által elhasznált áramot megspórolom a világítással.

Mivel a ház régi építésű, sokáig - egészen tavaly tavaszig - nem volt bekötve a 110-es szennyvízcső. Így úgynevezett WC darálóra volt szükség, aminek a lényege az, hogy a szennyvízcsatorna-rendszer és a WC közé behelyezve áram alatt kell tartani. Valahányszor a WC tartály öblít, a daráló az azon átömlő tartalmat szó szerint ledarálja, hogy az ne dugítsa el a szennyvízcsövet. Ennyi felújítás történt a házban tavaly, hogy a csatornarendszer fel lett újítva, így a darálót ki lehet szedni a rendszerből. Eredmény: egy fogyasztóval kevesebb.

Társasházi számladíj-csökkentés odafigyeléssel 1. rész

Thu, 10 May 2012 12:12:57 GMT

Lakásomban egy év alatt a gázszámla 5752 Ft-ról 4952-re, a villanyszámla 4136 Ft-ról 3715-re csökkent. A vízfogyasztás is mérséklődött 10%-al.

A lakásban 1 évig lakott nővérem (24 éves, egyedül élő, dolgozó nő). A lakást 7.30-kor hagyta el és általában 17.00 körül ért haza. Mikor Budapestre kerültem, akkor ő összeköltözött barátjával, akivel már össze is házasodtak, és vidékre költöztek. A lakásba be tudtam költözni, most én lakom itt egyetemistaként egyedül.

A nővérem sem folytat energiapazarló életmódot, átlagos fogyasztónak nevezném. Számos - energiafogyasztási szempontból lényeges -, alapvető különbség van a közte és közöttem. Napközben többet vagyok itthon. Egyrészt, mert közel lakom az egyetemhez és 1-1 szabad órára is haza tudok jönni – például ebédelni, másrészt, nincs előadás egész nap. Nővéremmel ellentétben, én nem nézek tv-t, ritkán használok hajszárítót, rövidebb ideig zuhanyozok, nem használok olvasólámpát elalvás előtt olvasáshoz. Viszont többet vagyok PC előtt és elalvás előtt tabletPC-n olvasok.

Tények

Adott egy 27 m2-es lakás a Budapesten egy belvárosi utca egyik társasházában. Az épület műemlékvédelem alatt áll, így a szigetelés és a nyílászárók cseréje nehezen – vagy egyáltalán nem megoldható. Az épület 4 szintes, belső udvaros, körfolyosós. A lakás a 3. emeleten van, mindkét oldalt van szomszéd, akárcsak a lakás alatt és felett is. Így csak 2 oldali fűtetlen fal van – egy a folyosó felől, egy pedig az épület másik oldala. A beltér magas és mivel az alapterület kicsi, így galériát építettünk be, ahová egy matrac került.

Motiváció, alapelvek

Egyetemistaként minimális önálló jövedelemmel rendelkezem, így a lakás rezsi-költségét a szüleim fizetik. Szeretnék legalább az által terhet levenni a vállukról, hogy odafigyelek arra, hogy mikor mivel tudom minimalizálni a kiadásokat. Másrészt régebb óta érdeklődöm az energetika iránt. Figyelem a megújuló energiahordozókra irányuló kutatásokat és elképzelhetőnek tartom, hogy ezen a területen dolgozom majd. Zavar a jelenlegi fenntarthatatlan fejlődés és úgy döntöttem, hogy legalább a saját lehetőséghez képest mindent megteszek, hogy a Föld ne menjen tönkre - bár tisztában vagyok vele, 27 m2-en nem fogom megváltani a világot.

“Minden számít”. Ezt a mondatot egy motivációs trénertől hallottam és úgy gondoltam, hogy ez igaz lehet az energiatakarékosságra is. Ezért törekszem a legapróbb részletekre is odafigyelni és mindent nagyobb hatásfokkal végezni, még akkor is, ha az eredetihez képest csak kicsi megtakarítást jelent. Sok kicsi sokra megy. Azonban a kényelmi szempontokat nem adom fel, értem ezt úgy, hogy nem fogok fagyoskodni a lakásban, és nem olvasok gyertyafénynél, mert bár a gáz és a villanyáram nem olcsó, még mindig olcsóbb, mint a gyógyszer a megfázásra vagy a szemüveg a látásra.

A lakásban 3 fogyasztásmérő van: a villany-, a gáz- és a vízóra. Mindegyiknek az állását március közepe óta egy alkalmazás segítségével naponta rögzítem (legalábbis amikor Budapesten vagyok). Ezáltal kimutatást készíthetek az időszaki energiafelhasználásokról.

Gáz

A gázt a Fővárosi Gázművek Zrt. szolgáltatja köbméterenként bruttó 117.5 Ft-ért. Ehhez még hozzáadódik évente 12312 Ft éves alapdíj (ami havonta nagyjából 1000 Ft) és némi készletezési díj. A gáz elsődleges felhasználása természetesen a fűtés, de a sütés-főzés is azzal történik, mivel csak egy nagyjából 40 éves, lábon álló gáztűzhellyel rendelkezem. Bár a sütés-főzés nincs évszakhoz kötve, volumenét tekintve mégis elhanyagolható a fűtéshez képest. Sem nővérem, sem én nem sütünk-főzünk rendszeresen, csak nagyjából hetente 1-2x. Esetemben még van példa arra, hogy szenet gyújtok be a tűzhelyen vízipipához. Ehhez - legutóbbi mérésem szerint - 0.069 m^3 gáz elégetése szükséges, aminek ára maximum 9 Ft.

A fűtés már többe kerül. Tény, hogy a lakás hőmérsékletének 1 °C-al történő emelése esetén a kiadás 6%-al nő. Nővérem jellemzően 21-22 °C-ban érezte jól magát, ezért ilyen hőmérsékletet tartott a lakásban, ha otthon volt. Azzal tisztában volt, hogy érdemes lejjebb venni a fűtést, ha hosszabb időre elmegy otthonról. Ilyenkor télvíz idején - ha el nem felejtette - kicsit visszábbtekerte a szabályzót, így biztosítva, hogy mikor hazaért akkor sem lesz hidegebb 19-20 °C-nál, de azért mégis spórolt.

Vele ellentétben én megelégszem a 20 °C-al. Aludni a fent, a galériában szoktam, ahol melegebb van (mivel magasabban van). Ezért lefekvés előtt is kicsivel lejjebb veszem a fűtést. Több tanulmány készült arról, hogy mi az optimális hőmérséklet az alváshoz. Legtöbb azt vallja, hogy a 18-21 °C között a legpihentetőbb az alvás. Ha melegebb van, akkor az ember nem tud nyugodtan aludni, úgynevezett mikroébredések jelentkeznek, ami másnap fáradságot, hosszabb távon pedig stresszt okozhat. A konvektor leszabályozásakor azonban nem szabad túlzásba esni, ugyanis minél hűvösebb van a szobában, annál nagyobb valószínűséggel lesz az ott alvó embernek rémálma.

Ha a lakást hétvégére, vagy hosszabb időre elhagyom, akkor a konvektort csak gyújtólángon hagyom, ami kb. 17 °C-ig engedi lehűlni a lakást. Ezt sosem felejtem el, van egy “teendők a lakás elhagyása előtt” listám, amin mindig átfutok, ha elutazom.

A párologtatás a hőérzetet javítja. Emellett egészségesebb is a párásabb levegő a száraznál - ez utóbbi a szem és a nyálkahártya száradását okozhatja, ami megbetegedések oka lehet. A lakás szellőztetése is fontos, melynek ideje alatt a fűtést érdemes letekerni. 5 perc szellőztetéssel a levegő kicserélődik, de a falak és bútorok nem hűlnek le.

Érdekesnek és hasznosnak találom a sörkollektort. Ez egy házi készítésű napkollekektor. Elkészítése nem túl bonyolult, csak az üres sörös dobozok alját és tetejét kell levágni, majd a hengereket csővé összeilleszteni és lefújni fekete festékkel. Az elkészített csöveket a háztetőre fel kell tenni, majd a cső mindkét végét be kell vezetni a fűtendő helyiségbe, ahol egy - például régi, 12 Voltos processzorhűtő - ventillátorral a cső egyik végén a levegőt befelé, a másik végén pedig onnan kifelé kell fújni. Így a levegő a tetőn lévő fekete sörös dobozokon átáramolva felmelegszik, és úgy kerül vissza a helyiségbe. Sajnos a budapesti lakásban ilyen rendszer kiépítésére lehetőségem nincs.

Épület falazatának EPS szigetelése

Mon, 23 Apr 2012 19:05:35 GMT

Egyetemen hallgatok építőmérnöki alapismereteket is. E tárgy keretében házi feladatot kellett készíteni: a feladat egy épület építési folyamatának tetszőlegesen kiválasztott szerkezeti részletét bemutatni egy általam kiválasztott anyag segítségével. A szerkezeti részlet, amit választottam a falazat külső hőszigetelése. A szerkezeti elem anyaga: expandált polisztirol hab. És íme:

A családi házak 80 év alatt várható energiafelhasználásának kimutatása szerint a legtöbb energiát a fűtés igényli (6x annyit, mint a második helyen álló használati meleg víz). A kisebb hőszigetelő képességű falazat építési költsége rendszerint kisebb, viszont az üzemeltetési költség nagyobb, mint a nagyobb hőszigetelő képességű falazaté. Helyes tervezés esetén a feladat tehát az optimumkeresés és hatékony hőszigetelő anyagokkal lehet megoldani (hivatkozás: Tk. 16.1 fej., 595. old., 2. bek.). Másik fontos és járulékos szempont a fenntartható fejlődés, miáltal a megújuló források fogyasztása kevesebb, mint amit a természet újrateremteni képes. A helyesen tervezett szigetelés következményeképpen a fűtésenergia csökkenése ehhez hozzájárul.

Az környezeti hőmérséklettartomány -20 és +70°C közötti, tehát az építészeti hőmérséklettartományban van (hivatkozás: Tk. 16.2.4. fej., 599.old., 3. bek.). A legfontosabb hőtechnikai anyagjellemző a hővezetési tényező (λ), amivel az anyagok hővezetési képességét jellemezzük. Ez az a hőmennyiség J-ban kifejezve, ami 1 m2 felületű, 1 m vastag falon állandósult hőáramban 1 óra alatt átvezetődik, ha a fal két oldalán a hőmérsékletkülönbség 1°C. Mértékegysége: W/(m*K). Minél kisebb valamely anyag hővezetési tényezője, annál jobb hőszigetelő (hivatkozás: Tk. 2.2.6. fej., 85. old., 7. bek.). A hővezetési tényezőt első sorban az anyag vegyi összetétele, kristályos, ill. amorf felépítése, testsűrűsége határozza meg (hivatkozás: Tk. 16.2.1. fej., 597. old., 16.2. ábr.), de nagymértékben függ a nedvességtartalomtól, hőmérséklettől és lemezes anyagok esetén a hőáramlás irányától is. A hőszigetelő anyagok pórusos szerkezetűek, azaz szilárd anyagokból és levegőből tevődnek össze. Ebből következik, hogy nem tisztán jelentkezik a hővezetés, hanem azt többé-kevésbé torzítja a hőáramlás és a hősugárzás is (hivatkozás: Tk. 2.2.6 fej., 87. old, 1. bek.).

A választott szerves hőszigetelő-anyag a polisztirol hab. Maga a polisztirol (PS) amorf műanyag. Lágyuláspontja 65-100°C. Vízálló, igen jó vegyszerálló, fényálló, éghető. Legtöbb oldószer oldja. Jól forgácsolható, hegeszthető, ragasztható. Az építőiparban elsősorban hab, csempék, lemezek, fóliák formájában használják (hivatkozás: Tk. 13.2.1. fej., 497. old., 6. bek.). A polisztirol habot Magyarországon két lépésben állítanak elő. Az első lépésben az előhabosítás során sztirolszemcsék gőzben (vagy melegben) a bennük lévő kelesztőanyag hatására 1-8 mm-es gyöngyökké duzzadnak. Ez szemcsés anyagként felhasználható hőszigetelésre is. A polisztirol gyöngy pihentetése után a második lépésben zárt sablonban tovább habosítják és kapják a polisztirol hab tömböt, amely testsűrűsége hat csoportba sorolható. Ez az érték 12-40 kg/m3 között változik. Hővezetési tényezője 0,03-0-0,04 W/(m*K). Tartósan 80°C-ig hőálló. Pórusrendszere majdnem teljesen zárt, nem áll ellen a tömény savaknak, szerves oldószereknek, ásványolajoknak, kőszénkátránynak (hivatkozás: Tk. 16.2.6. fej., 607. old., 5. bek.).

A célra megfelel pl. a MasterPlast Kft. által forgalmazott ISOMASTER EPS-30 márkajelű, 0.25 m3/bála = 5 m2/bála kiszerelésben kapható EPS (röv. Expanded Polystyrene - Expandált Polisztirol). A lapok falazatra történő felragasztása EPS habarccsal történik. A falazóhabarcsok feladata a falazóelemek közötti együttműködés létrehozása, a teherelosztás, a hézagkitöltés és az építőelemek összeragasztása (hivatkozás: Tk. 8.5.1., 348. old., 4. bek.). Az említett habarcs megfelelő mennyiségű mészkő és agyag zsugorodásig való égetése által előállított klinker és kötésszabályozás céljából hozzáadott gipszkő együttes finomra őrölése révén készített portlandcementen (hivatkozás: Tk. 6.3.1. fej., 215. old., 5. bek.) és polimeren alapszik. A becsült átlagos ragasztóhabarcs-anyagszükséglet: 4.5 kg/m2.

A felhelyezés módja: a ragasztóanyag egyoldalra kerül felhordásra, a lemez hátoldalára rozsdamentes acél spaklival a lemez széle mentén folyamatos sávokban és még középen 4-6 helyen pontszerűen vagy két sávban. A felhordott ragasztó mennyisége akkora, hogy amikor a lemezt felnyomják a felületre, a lemez legalább 40 %-át borítja be. A lemezeket szorosan egymás mellé kerülnek úgy, hogy a ragasztó nem folyik bele az érintkező résekbe. A burkolat külső felületének egyenessége ragasztás közben folyamatosan ellenőrizendő. A szomszédos sorokban elhelyezkedő lemezek a téglakötés szabályainak megfelelően tolódnak (hivatkozás: www.jub.hu).

Felhasznált irodalom:Dr. Balázs György - Építőanyagok és kémia, Műegyetemi Kiadó, 1983

Ingyen repülőjegy a Westendben

Fri, 17 Feb 2012 20:54:12 GMT

Pont 2012. február 14-én hívott egy nem Budapesten lévő ismerősöm: az index.hu-n most olvasta, hogy 1000 db ingyen repülőjegyet oszt szét a Ryanair, ha ráérek, menjek én is, hátha jut. Pont ráértem, szóltam is pár ismerősnek, akikről gondoltam, hogy érdekelheti őket. Egy ismerőssel 2-en mentünk.

Tudtuk, hogy 16:00-tól osztják és hogy viselni kell valami kéket. Nem találtuk első körben a hostesseket, de - mint később kiderült - azért, mert nem jó szinten kerestük. 4 óra előtt kb. 10 perccel viszont odataláltunk és szemmel láthatóan jó helyen jártunk, ugyanis elég nagy volt tömeg. Saccoltuk, vajon benne leszünk-e az első 1000-ben. Végül úgy döntöttünk, várunk, max. nem jut jegy. Mögöttünk is hosszúra nyúlt a sor, lassan is haladtunk, de kb. 1 óra 10 perc sorban állás után kaptunk 1-1 vouchert, 1 lapot az utazási feltételekről és gyors szóbeli tájékoztatást, hogy hogyan is kell foglalni.

A voucher-re rá van írva, hogy az utazás 1 alkalomra szól, oda-vissza érvényes a következő városok valamelyikére (természetesen Budapestről): Brüsszel, Baden Baden, Göthenburg, Hamburg, Memmingen, Milánó. Értelemszerűen és angolul kell kitölteni a mezőket és szkennelve elküldeni a megadott e-mail címre. 1 úti célt és 3 lehetséges utazási- és érkezési időpontot kell megadni.

A voucher felhasználására kapott időintervallum nem nagy, tehát mindenkinek kapkodnia kell, hogy kapjon jegyet. Mi is így tettünk, amint meglett a jegy, jöttünk hozzám, kikerestük a Ryanair honlapján, hogy mikor indulnak gépek Brüsszelbe - és vissza. A voucher lejártáig 2 hétvége van. Nekünk a soron következő semmiképp nem lenne jó, így az azt követőt pályáztuk meg: február 24-én indulás, 26-án vissza. Útitársammal egyforma sorrendben tüntettük fel az időpontokat és a szkennelt vouchert nagyjából 1-2 perc különbséggel küldtük el a megadott e-mail címre. Másnap kaptam is két levelet: egyik magyar nyelvű volt és írta, hogy köszönik, hogy részt veszek a promócióban és másik levélben küldik a foglalási kódot és a további részleteket. A másik levél hosszú volt és angol, de ott volt a tetején a foglalási kód az elsőnek megjelölt hétvégi gépre. Felhívtam hát partnerem és kérdeztem, ő kapott-e levelet. Csak a magyar nyelvűt kapta meg, a másikat nem. Estére aztán megkapta az angol nyelvűt is, viszont ő a harmadikként megjelölt hétköznapi időpontokra. Így mehetünk mind a ketten külön, de együtt nem - az átfoglalás költséges.

/* A következő sorok saját elmélkedésen alapulnak, nem kérdeztem meg sem a Ryanair-, sem a Liszt Ferenc Nemzetközi Repülőtér illetékes szerveit, csak építek egyetemi tanulmányaimra és józan eszemre. Ez egy blog, nem hírportál. */

Miért osztogatnak csak úgy repjegyet?

Biztosan lesz majd jó sok illeték meg minden! - mondják a “jól értesültek”. Nem hiszem. De tény, hogy nem fenékig tejfel itt minden. Egy kézipoggyászt vihet az ember ingyen, a többi már fizetős. Ez oké, 2 napra elég is annyi. Ezt nem tartom átverésnek. A lényeg a marketing. Amint a MALÉV csődöt jelentett, a Ryanair egyből bejelentette, hogy sok új járatot indít Magyarországról - nyilván a MALÉV jelentésekből látszott, hogy nem jól megy a szekér és várható volt a csőd. Ezt kihasználta a Ryanair - nagyon okosan. A fiókban már ott lehetett a kész stratégiai terv, hogy milyen lépéseket tesznek egy komoly szereplőt elvesztő piacon. Akik korábban nem hallottak a Ryanairről, azok február 14-én a Westend City Centerben biztosan megtudták, hogy mi az. Elég volt elhinteni az index.hu-n utolsó bejegyzésként, hogy lesz néhány ingyen jegy és máris odament néhány ezer ember sorba állni, mert hát habzsi-dőzsi, meg ingyen jegy, pedig egy részük feltehetően amúgy nem is akart utazni, csak ha már ingyen van. Viszont az emberek ritkán utaznak egyedül, inkább ketten, vagy többen együtt. Ha a voucher-t felhasználók között a jegyeket kiosztják, akkor valószínűleg véletlenül, de előfordulhat (ahogy nálunk is előfordult), hogy az útitársak külön gépre kaptak jegyet. Mit lehet ilyenkor tenni? Az átfoglalás költséges (azt hiszem, drágább, mint új jegyet venni). Másik lehetőség - egy páros utazásra gondolva -, hogy a preferáltabb időpontot kapott utazó és a szerencsétlenebb útitársa azt mondja, vegyünk még egy jegyet arra az időpontra, amikor neked van jegyed és felét te fizeted, felét én, még így is féláron utazunk. Ne felejtsük el: lehet, hogy egy hete még nem is akartak utazni. Már itt is nyer a légitársaság. Arról nem is beszélve, hogy ha egy társaság 2 tagjának sikerül azonos gépre kerülni, akkor lehet, hogy a barátok megkívánják a lehetőséget és csatlakoznak önköltségen.

Ahhoz, hogy lássuk, milyen időpontokban indulnak gépek (ezt a voucher-eseknek kötelező), fel kell menni a Ryanair honlapjára és ki kell keresni. Itt az árak is fel vannak tüntetve. A mi brüsszeli hétvégi utazásunk fejenként 14800 Ft lett volna, de nézelődés közben olyat is láttunk, ahol 2500(!)-3000-5000 Ft-ért oda-vissza meg lehet járni Brüsszelt. Ezekről a szerintem igencsak pénztárcabarát árakról én nem tájékozódtam volna, ha nem nyerek voucher-t és nem lépek fel a honlapra. És én ezt elmondtam azóta legalább 20 ismerősömnek. Ebből kiindulva, ha mind az 1000 ember, aki jegyet kapott, csak 2 embernek mondja el, akkor is már 3000-en tudják, hogy a Ryanairnél mennyibe kerül a repülőjegy. Így már nem is annyira nagy érvágás, ha az adott záros határidőn belül nem tudunk gépre szállni, majd elmegyünk márciusban, vagy később - nem egy ökör ára.

Az is biztos, hogy az 1000 kiosztott ingyen jegyből nem fog 1000 ember utazni - 2-vel már biztosan kevesebb lesz, mert mi nem megyünk. A Ryanair jól csinálja: ott támad, ahol lehet. Nem hiszem, hogy így a sallangokkal együtt ez az eljárás sokszorosába került egy tartós rádió- vagy tévéreklámnak, de volt olyan - vagy nagyobb hatása. Ugyanúgy bekerültek a tévébe és rádióba, csak nem a reklámblokkba, hanem a híradóba.

Nincs minden ingyen

Azt azért hozzá kell tenni, hogy aki felhasználja a jegyet, ő sem fog valószínűleg 0 Ft-ból kijönni. Ki kell jutni a Liszt Ferenc reptérre, ahol leszáll, onnan valószínűleg elmegy valahová, nézelődik, vesz csecse-becsét, esetleg megszáll egy hotelben/motelben/panzióban/stb, majd visszamegy a reptérre, hazarepül ingyen és a hazai reptérről is hazamegy. Ahogy számolgattuk nem a repülőjegy vásárlásnál kell a zsebbe nyúlni, hanem a szállásnál és az euró-vásárlásnál. Viszont fenntartom: (nekem) jó, hogy ennyibe kerülnek a repülőjegyek, mert legalább azon lehet spórolni.

Napi motiváció 1.

Thu, 16 Feb 2012 11:20:10 GMT

Megérdemled, hogy boldog légy!

Hogyan lehet az ember boldogabb és sikeresebb? A Brian Tracy International szerint van rá tanulható módszer. Elmondom, hogyan.

Minden ember különbözik

Nem mindenkinek ugyanaz jelenti a boldogságot. Olyan ez, mint egy terített svédasztal. Odamegy hozzá sok ember és mindenki mást szed a tányérjára, a rengeteg hús, zöldség és köret segítségével sok különböző kombinációban lehet megpakolni az egyes tányérokat. A boldogsággal is ez a helyzet, minden ember magának találja meg a boldogságának összetevőit és az alapján „rakja meg tányérját” – vagyis tölti meg életét.

Hallgass a szívedre

Az ebéded összetétele azonban változik, ha minden nap ugyanabból a kínálatból választasz. Ilyenkor megkérdezed magadtól, hogy mi is az, amit ma kívánsz? Így van ez a boldogsággal is, kérdezd meg magadtól, mitől leszel boldog, mire vágysz? Ez a legjobb módja annak, hogy kiderítsd, milyen munkára, kapcsolatra, befektetésre vágysz. Ez alapján tudsz helyes döntéseket hozni. Hallgass a szívedre.

Légy őszinte önmagadhoz

Csak akkor vagy őszinte önmagadhoz, ha azt teszed, amit a „belső hangod” diktál. Figyelj oda erre a belső hangra, légy bátor és fogadd el, amit ajánl.

Nincsenek határok

A boldogságot megérdemled. Ha ezt a kijelentést elfogadod, használod a tehetségedet és képességeidet, akkor nagyon jó úton jársz ahhoz, hogy boldog légy. Minél jobban szereted és tiszteled önmagad, annál jobban kiérdemled a jó dolgokat az életben. Tudod, vonzás törvénye: amire sokat gondolsz, megtörténik, így, ha jó dologra gondolsz, jó dolog történik veled.

A boldogság a legfontosabb

Remek módszer, ha megtervezed, hogyan legyél boldog. Pontosabban eldöntöd, mitől leszel boldog és azt tervezed meg, hogy hogyan éred el azokat, amiktől boldog leszel. Hasonlíts össze, minden lehetséges tevékenységet és döntést, ami boldoggá vagy boldogtalanná tehet. Rá fogsz jönni, hogy minden problémádért te vagy a felelős, te döntöttél úgy, hogy azt teszed, illetve hogy nem teszel ellene. Miután erre rájöttél, ideje elgondolkozni azon, hogyan tudod elgörgetni ezeket az akadályokat a boldogságod elől.

Fizesd meg az árát

Természetesen számtalan olyan eset van, amit muszáj megtenned, de tudod, hogy nem leszel tőle boldogabb. Mivel azonban meg kell tenned, meg is teszed, de utána abból a szempontból jobb lesz, hogy túl leszel rajta. Ezeket az ideiglenes lépéseket – melyek közvetlenül nem boldogítanak - meg kell tenned ahhoz, hogy utána foglalkozhass a kellemesebb dolgokkal, hogy boldog lehess. Ez a siker ára. Ezt ki kell fizetni.

Gyakorlatban

Itt van 3 lépés, amit már most meg tudsz tenni, hogy ezeket a fenti ötleteket a gyakorlatba ültesd:

Fogadd el, hogy megérdemled a boldogságot és saját erőfeszítésed révén elérheted azt
Készíts saját tervet a boldogság eléréséhez
Légy hajlandó keményen dolgozni a boldogságért és fizesd is meg annak árát.

Gondolkozz előre és figyelj a céljaidra és a sikeres leszel.

Forrás

Brian Tracy hírlevél 2012. február 6. „You deserve to be happy” | A használat engedélyezett a Brian Tracy International Support Team által.

jQuery 30 nap alatt II. rész

Wed, 15 Feb 2012 19:07:31 GMT

Az előző rész tartalmából:

Tutsplus.com ajánlata a következő: megtanítja nekem (és bárki másnak is) 30 nap alatt a jQuery használatát ingyen.

7. nap

3 fontos metódus kerül ma bemutatásra, így:

.bind()
.live()
.delegate()

E 3 eljárás mindegyike gyakorlatilag egy pointer (mutató) az .on()-ra. Szó esik még a .clone() és .appendTo() funkciókról is.

8.nap

A DOM-hoz adás eljárásairól van szó. Azaz, például hogyan lehet a HTML kódhoz hozzátenni új tartalmat jQuery-vel.

.append() : utána fűzi a zárójelben lévő tartalmat a kijelölt terület végéhez
.prepend(): annyiban más az .append()-nél, hogy nem a „this” után, hanem elé fűz
Az .after() és .before() arra szolgál, hogy közvetlenül egy megkeresett tag/osztály után és elé szúrja be a zárójel tartalmát, nem pedig a kijelölt tag-en belülre (ahogyan azt az .append() és .prepend() teszik).

Új tartalom hozzáadás tag-gel együtt egy „article”-höz:

$(’<h2></h2>’, {
  text: ’ez lesz a h2 tag-eken belül’,
  class: ’osztaly’,
}).appendTo(’article’);

Az .appendTo() a végére illeszt az article-nek, a .prependTo() pedig az elejére. Használható még az .appendTo() helyett az .insertBefore() vagy .insertAfter() is, ilyenkor a zárójelben megadott tag/osztály elé vagy utána teszi az új tartalmat.

Végül egy olyan scriptet írt Jeffrey, ami például blog-bejegyzéseknél használatos: a <span class=”co”></span> tag-ek közötti szöveget oldalra igazítva, felnagyítva és egyéni háttérrel ellátva blokkidézetként jeleníti meg. Egész jól néz ki.

9. nap

A slide-ról és fade-ről lesz ma szó. A példában egy „contact me” gombra kattintva lecsúszik a weblap tetejéről egy űrlap. Amit már az elején leszögez Jeffrey, hogy mindig a HTML-el kezdjünk (és CSS-el). Ne ugorjunk neki egyből a JavaScriptnek vagy jQuerynek. Jelen esetben ez azt jelenti, hogy először egy „nyers” HTML váz készült, ahol rendre megjelenik az adott szöveg és contact me gomb, alatta pedig az űrlap, ami majd a script elkészítése után csak a gombra kattintva jelenik meg.

Érdekes a JavaScript (JS) engedélyezettségének ellenőrzése. A formot (űrlapot) „fel kell ragasztani” az oldal tetejére. Ennek definiálása egy css osztályban történik (.js body #form). Alapból a html-hez nincs hozzáadva semmilyen osztály. A script úgy kezdődik, hogy $(’html’).addClass(’js’). Ezáltal aktívvá válik a .js body #form definíció a css-ben és felragad a form a weboldal tetejére és eltűnik (gombnyomásra pedig előjön). Ha a böngészőben nincs engedélyezve a JS, akkor viszont a html tag-hez sem lesz hozzárendelve a js osztály, így a definíció sem lesz érvényes, tehát a form nem takarja el a tartalmat.

Ha ugyanazokkal a paraméterekkel használjuk a .slideUp() és .slideDown()-t vagy a .fadeIn() és .fadeOut()-ot, akkor helyettük használható a .slideToggle() és .fadeToggle().

Megjegyzem, ez az eddigi legbonyolultabb rész. Kicsit hosszú is a korábbiakhoz képest (~24 perc) és eléggé belemegy itt a call funkcióba, ide-oda hivatkozik. A végén ezt el is ismeri és ajánlja, hogy nézzük meg újból, ha nem volt minden tiszta elsőre. Igencsak élek a lehetősséggel.

10. nap

Jeffrey egy 10 perces előadást szentel most a this megértetésének. Tüzetesen vizsgálgatjuk, hogy mi változik, ha változtatjuk a this környezetét, vagy helyét a scriptben. Amiről már tegnap is volt szó, de nem ejtettem róla szót az az, hogy van egy számomra új módja is a funkciókészítésnek:

var  cif = {
  akarmi: function(){
    console.log(this);
  }
}

Ez esetben az akarmi meghívása így történik (például): $(’a’).on(’click’, cif.akarmi);

Szó esik a .preventDefault()-ról, a .call()-ról és a .proxy()-ról is.

11. nap

Rövid előadás következik az effektek sebességéről. A jQuery forrásfájlban lévő .fx.speeds-ben található értékeket figyeljük meg, majd módosítjuk azokat. Ezek a módosítások természetesen nem magában a jquery-1-7-1.js-ben, hanem a mi HTML állományunkban történik. A forrást nem piszkáljuk. Vannak előre definiált sebességek. Például: .slideDown(’slow’) az 600ms, de ha a zárójelbe fast-et írunk, akkor az 200ms lesz. Az alapértelmezett érték 400ms. Újat is definiálhatunk a $.fx.speeds.nagyonlassu = 6000;-el például. Ilyenkor, ha a .slideDown() zárójelébe a ’nagyonlassu’-t írjuk, akkor ugyanaz történik, mintha 6000-et írtunk volna.

12. nap

Megtanulhatjuk, hogyan írjunk saját scriptet arra, hogy egy <h1> elemre kattintva automatikusan megjelenjen néhány bekezdés, majd pár másodperc múlva tűnjön is el. Ehhez a jQuery forrásból kimásoljuk a slideDown definíciója után következő jQuery.fn[] kezdetű részt és azt módosítjuk.

Azt szeretnénk, hogy addig ne fusson le a következő parancs, amíg az aktuális effekt le nem fut teljesen. Ezt úgy valósítjuk meg, hogy hozzáfűzzük a 2. parancsot az effekthez:

$(this).slideDown(300, function(){
  //ez csak akkor fut le, ha már a slidedown lefutott.
});

A várakoztatásra van előre elkészített eljárás jQuery-ben: a .delay(), ahol a zárójelben megadható, hogy mennyi idő teljen el addig (milliszekundumban), míg a következő utasítás lefut.

Összegzés

Fenntartom továbbra is, hogy érdemes elkezdeni és folytatni ezt a sorozatot. Hasznos időtöltés, nem megerőltető, de azért igényel némi gondolkodást, ha tényleg meg akarja valaki érteni. Ez a kivonat, amit itt publikálok, közel sem helyettesíti a videókat, nem azért csinálom. Inkább arra jó, hogy emlékeztet engem - és bárkit, aki a végigcsinálja a tanfolyamot -, hogy melyik részben mi is volt. Így, ha kérdés merülne fel, akkor gyorsabban megtalálható az a rész, amelyikben a kérdésre választ kaphatunk. 12 napnyi videót néztem meg eddig, az utóbbiak 10 percnél is kevesebbek. Mégis úgy érzem, jQuery-vel gyakorlatilag bármit meg lehet tenni és máris hasznosítható tudással rendelkezem. DE természetesen megnézem a többi részt is!

Mi az az energia?

Tue, 14 Feb 2012 09:16:39 GMT

Szükségesnek érzem, hogy ebben a témában először tegyük tisztába, hogy mi is az az energia és milyen fajtái vannak.

Energia: munkavégző képesség

Kicsit hétköznapiasabban fogalmazva: azért van, hogy el tudjuk végezni a dolgainkat, mivel a társadalom és a gazdaság működése energiát igényel.

Energiahordozók

Primer

Fosszilis

szén
kőolaj
földgáz

Megújuló

Feltétel nélkül megújuló

Nap
szél
geotermia

Feltételesen megújuló

biomassza
tűzifa

Atomenergia

Szekunder

hőenergia
villamos energia

A primer energiahordozók a természetben megtalálhatók. Ezek közül a fosszilis kategóriában vannak azok, melyekből a készlet gyakorlatilag véges. A megújulók között a feltételesen megújulók azok, melyek az emberektől függetlenül “működnek”, ha az ember kihasználja, akkor nyer vele, ha nem, akkor nem - de azok akkor is működnek. A feltételesen megújuló annyiban más, hog ezek is megtalálhatók a természetben és újra lehet termelni, de ehhez mesterséges beavatkozás szükséges - tehát ha egy erdőt kivágunk tűzifának, akkor sok energiát nyerünk vele, de ha nem ültetünk a helyére új fákat, akkor ez a forrás kiapad. Viszont azáltal, hogy fennáll az újraültetés lehetősége, maga a forrás megújítható. A primer energiák előnye, hogy jól tárolhatók, viszont hátránya, hogy nehezen és/vagy költségesen szállíthatók.

Az energia azért kell, hogy valamilyen szükségletet kielégítsen. Viszont, a társadalomnak és a gazdaságnak nem közvetlenlenül az energiára van szüksége, hanem az azáltal létrehozott előnyre/könnyítésre - ami az ahhoz kapcsoldó szükségelet kielégíti -, ez többnyire mechanikai- vagy hőenergia formájában jelenik meg (mozogjon az autó, legyen fűtés a házban). A szekunder energiahordozó már az, amit a primer energiahordozókból előállítottak az “erőmű” által: hő- és villamos energia. Ezek könnyeben szállíthatók (vezetéken), viszont a szállítás sok esetben veszteséggel jár. Ráadásul a szekunder energia tárolása nehézkes és szintén veszteséges.

jQuery 30 nap alatt I. rész

Thu, 09 Feb 2012 20:52:39 GMT

Tutsplus.com ajánlata a következő: megtanítja nekem (és bárki másnak is) 30 nap alatt a jQuery használatát ingyen.

Ez az ajánlat több szempontból is vonzó számomra:

Érdekel a jQuery
Anyagi vonzattól mentes
Nincs semmi veszítenivaló

Az oktatás úgy működik, hogy e-mail címünk megadása és megerősítő e-mailben megfelelő linkre kattintás után naponta kapunk egy linket, ami egy videóra mutat. Jeffrey Way tartja az “előadásokat”, aki az Envato online oktatóközpont egyik tanára. Korábban már találkoztam vele egy Rails videóban.

Úgy döntöttem, hogy nagy vonalakban, vázlatosan leírom az aktuális napi videó tartalmát. Ez abból a szempontból is jó, hogy emlékeztet arra, hogy mit hol is láttam, így egyszerűbb lesz a visszakeresés vagy utánanézés. Mivel ezek a kis vázlatok nem hosszúak, tényleg csak pár címszó, esetleg megjegyzendő példa, így nem minden nap születik róla bejegyzés, hanem mondjuk 6 részenként.

Íme az első hat nap tanulsága:

1. nap

Egyből 2 videót is kaptam (mármint linket, amin keresztül online nézhetem, nem kell letölteni). Egyik egy rövid (38 másodperces) ismertető Jeffrey Way-től, az oktatótól. Itt elmondja, hogy adjak neki napi 15 percet és 30 nap múlva jQuery pro leszek. Jó.

A második videó már 11 perces (1 mp híján). Lehetőség van a videó letöltésére és a projekt fáljok letöltésére is. Ez a rész a jQuery library-król, letöltésükről és html kódba illesztésükről, és a selector-okról szól. Teljesen jól érthető, követhető és logikus. Az alapoktól kezdi a tanfolyamot (nagyon helyesen), de tény, hogy ezekkel már tisztában voltam, mivel kicsit tanultam jQuery-t. Viszont, ha nem tanultam volna, akkor most megértettem volna.

2. nap

7 perces videó, abból is csak egy. Tarthatónak tűnik a napi 15 perc – nyilván ha magam is végig próbálom a videóban bemutatottakat, akkor máris megvan a negyedóra. A document.ready kerül bemutatásra. Egy html oldal betöltésekor a böngésző soronként értelmezi a html-t így, ha a jQuery kód előbb van, mint az kódrész, amin változtatni kell, akkor „meg kell neki mondani”, hogy várjon, amíg a teljes oldal (DOM – Document Object Model) be nem tölt, és csak aztán fusson le. Erre szolgál a $(document).ready(funtion{});, vagy rövidebben: $(function(){}); (előbbi érthetőbb, utóbbi rövidebb). Innen eredhet a napi tananyag elnevezése is: „Not so fast, jQuery” – azaz „Ne olyan gyorsan, Tudjukki”.

3. nap

Bizonyos metódusok (eljárások) kerülnek bemutatásra. Ezeket össze lehet keverni, - tapasztalatom szerint - kis gyakorlást igényelnek, de logikusak. Azért itt van pár példa:

$(’ul’).children(’li’); csak a közvetlen li-t jelöli ki, ami az ul-on belül van. Ha az ul-on belüli li-ben van egy másik lista elemekkel, akkor azok nem lesznek kijelölve.
$(’ul’).find(’li’); nem csak a közvetlen listaelemeket jelöli ki, hanem azokat is, amik egy, vagy több szinttel lejjebb vannak, tehát az mindazt, ami az <ul> és </ul> tag között van.
$(’ul’).children(’li’).eq(2); a 3. listaelemet jelöli ki (mivel a számozás 0-tól indul).
$(’ul’).children(’li’).eq(1).next(); ez is a 3. listaelemet jelöli ki. A next() a következő a soron következő, ugyanazon tulajdonságú elemre mutat.
$(’ul’).children(’li’).eq(3).prev(); ez is a 3. listaelemet jelöli ki.
$(’li’).parent(); a közvetlen szülő kijelölése (zárójelben megadható a tag neve, ID-je vagy osztálya)
$(’li’).parents(.container); nem csak a közvetlen szülő, hanem az összes <li>-t közbezáró tag között keresi az összes container osztállyal rendelkezőt és azt/azokat jelöli ki.
$(’li’).closest(.container); annyiban tér el az előzőtől, hogy csak az adott listaelemhez legközelebbit jelöli ki, ha esetleg attól távolabb is van, azt már nem.

4. nap

Ez a nap az eseményekről (events) szól. Az oktató (Jeffrey) egy alapszintű honlaphoz készít css stíluslap cserélő scriptet. Szó esik a this-ről. Ez a következőképp néz ki:

(function(){
  $(’button’).click(function(){
    console.log(this);
  });
})();

Ilyenkor, ha egy gombra kattintunk, akkor a konzolban megjelenik az a gomb (html formában), amelyikre kattintottunk. Tehát a this egy olyan érték a függvényen belül, ami az aktuálisan kiválasztott/folyamatban lévő értéket adja vissza. Különbség van a sima this és a $(this) között!

Másik fontos dolog, amire rámutat ez a videó, az a változók használata. Pl.:

var uls = $(’ul’); ezáltal nem kell állandóan leírni, hogy $(’ul’), ha újra azt akarjuk használni, hanem helyette csak azt, hogy uls. Ez azért is jó, mert nem kell mindig az eseménynek DOM-ba „ugrani”, vagyis kevésbé terheli a böngészőt.
Adott elem attribútuma módosítható az attr-al a következőképp: $(’.link’).attr(’href’,’jaj.css’);
.siblings(): a kiválasztott elemmel azonos tulajdonságú és azonos szinten (pl.: ugyanazon div-ben) lévő másik elemet/elemeket választja ki.

5. nap

Ma egy táblázatszerű listát készítünk, ahol az egyes cellák felé mozgatva az egeret, jQuery-szerűen lenyílik egy kis sáv – lejjebb tolva az alatta lévő cellákat. Ha másik cella felé mozgunk, akkor a korábban lenyitott visszacsúszik (eltűnik) és lenyílik az éppen aktuális. A létrehozás ismét a váz megalkotásával kezdődik. Itt számomra új elem jelent meg, a

felépítésű „definíciós lista”. Szegyén-nem szégyen, nem láttam még ilyet (vagy legalábbis nem tűnt fel) és nem is volt rá szükségem. Példa rá a w3schoolból:

<dl>
  <dt>Coffee</dt>
  <dd>- black hot drink</dd>
  <dt>Milk</dt>
  <dd>- white cold drink</dd>
</dl>

Másik érdekesség számomra a Chrome Autosave plugin, ami lehetővé teszi, hogy a Chrome-on belül szerkesszük a CSS fájlt, ezáltal gyakorlatilag WYSIWYG (What You See Is What You Get - Kapod, amit látsz) szerkesztőt készítve a böngészőből.

CSS-el egész ügyes kereteket (border)-t állít össze Jeffrey. Kiderült, hogy a CSS3-ban már van olyan, hogy :nth-last-child(2) – ami az adott felsorolásban az utolsó előtti elemet jelenti.

Használt effektek: a .slideDown() és a .slideUp(). A zárójelbe írt szám az animáció sebessége ms-ban.

6. nap

Ma nincs videó. Helyette kisZH – vagyis gyors kvíz az eddig tanult alapokból. Nem nehéz, tényleg csak azokat kérdezte, amiket elmondott. 1 hibám volt, ami igazából annyira nem is volt hiba, csak a kérdésre, hogy „Mivel jelölök ki azonos szinten az aktuális elemen kívül minden mást?” annyit írtam, hogy „siblings” és lehet, azt kellett volna, hogy „siblings()”. Ezzel együtt is 92% lett a teszt, jó lenne egyetemen is ilyeneket írni, de hát az élet nem habostorta és a BME nem diplomagyár.

Konklúzió

Eddig egy napot sem hagytam ki és nem is tervezem a továbbiakban sem. A léptékek, ahogyan Jeffrey Way halad, teljesen jók, érthetően beszél és jól elmagyarázza a dolgokat. Láthatóan remek szakember, legtöbb apróságra kitér és elmondja, mi miért úgy működik ahogyan, és mi lenne másképp, ha mást máshogyan csinálna.

RubyMine telepítés és beállítás

Sun, 05 Feb 2012 21:34:08 GMT

Elmondom én mi a bajom nekem a Ruby on Rails-el (RoR-ral). A telepítése és beállítása. Jól lehet, én vagyok primitív, de nekem gyakorlatilag semmi nem sikerült elsőre eddig, amikor valamely tutorialt csináltam végig, vagy saját ötletet próbáltam számomra logikus módon megvalósítani.

Valahol mindig gubanc volt/van. Arra tippelek, hogy direkt csinálják ezt a fejlesztők, hogy ne lehessen Windows 7 alatt bárkinek csak úgy Ruby on Rails-el webes alkalmazásokat készíteni. Mikor egyetemen tanultam RoR-t, akkor Linuxon mutatták, hogy mi merre, így virtuális gépre feltéve egy Ubuntu Linuxot én is azon keresztül készítettem a házi feladatomat. Kényelmetlennek tartottam ezt, mivel - bár nem ismeretlen számomra a Linux, de Windowshoz vagyok szokva. Nem szeretek parancssorban zsonglőrködni, kattintgatni szeretek.

Nézelődés közben ma ráakadtam a Jetbrains RubyMine Ruby on Rails IDE-re (Integrated Development Environment). Az integrált fejlesztői környezet - mint a nevéből is kiderül - tartalmazza a fejlesztéshez szükséges eszközöket, mint például egy szövegszerkesztőt, fordítót, hibakeresőt, stb. Ez a RubyMine 30 napig ingyenes, gondoltam kipróbálom, nincs mit veszíteni. Elég terjedelmesre csinálta a cseh fejlesztőcsapat, mérete majdnem 100 mb. Telepítése nem bonyolult, setup.exe > pipa + next > next > stb. Első indításkor ajánlja, hogy adjuk meg a licenszkódot, vagy aktiváljuk a 30 napos próbalicenszet.

Akkor készítsünk egy próbaprojektet! (Azaz Create new projekt). A projektnév, elérési út megadása és a “Rails Application” kiválasztása után kéri, hogy adjuk meg a Ruby interpretert (egészségedre), Rails verziót, Rails template-et, JavaScript library-t és van még két jelölőnégyzet: egyik adatbázist, másik a test fájlok kihagyását ajánlja. Itt kicsit megfőttem, mivel az első mezőben (az interpreteresnél) valami [No SDK] (vagy hasonló) jelent meg, Rails verziót sem talált, és gondolom ezek miatt a többi opció nem is volt elérhető/módosítható, még az OK gomb sem. Rájöttem, hogy bár összeszedett programnak tűnik ez a RubyMine, de annyira mégsem hülyebiztos, hogy csak úgy sipsupp kész legyen. A rubyonrails.org/download oldalról le kell tölteni a windows-os telepítőjét a Ruby-nak (én a legújabb, 1.9.3-at töltöttem). Telepítőfájl, rákattintva és a megszokott next > next > next > finish-el telepíthető. Visszalépve a RubyMine projekthez interpreternek adjuk meg a feltelepített Ruby-nkat. Ehhez tallózással keressük meg a <ahová a ruby-t tetted>\bin\ruby.exe-t. Nálam tehát így néz ki: C:\Ruby193\bin\ruby.exe. Erre kattintva már varázslatszerűen elindult mindenféle egyéb folyamat, települt a Rails (még meg is kérdezte, hogy melyik verziót szeretném - de drága). Lehetőségem akadt már adatbázist és JavaScript library-t is választani. JQuery és MySql teljesen jó lesz nekem.

A projekt mappájában végre megjelentek a RoR-nál szokásos struktúrában rendezett fájlok. A RubyMine kis üzenetek formájában kiabált, hogy hiányoznak bizonyos gem fájlok, kattintsak oda a telepítéshez. Így is tettem, de a konzolban és az újra megjelenő üzenetben láttam, hogy nem ért a végére. Ajánlotta, hogy telepítsem fel a Development Kit-et, aminek a letöltési útvonalát is megadta és azt is, hogy a github-on találok leírást a telepítéshez. Egy önkicsomagoló 7z fájlt találtam, ez kicsomagolta magát és parancssorral ide navigálva itt kell kiadni a ruby dk.rb init parancsot. A parancssor azonban visszaszólt, hogy nem ismer olyan parancsot, hogy “ruby”. Némi keresgélés után rátaláltam, hogy ahhoz, hogy ismerje a parancsot, meg kell adni annak az elérési útvonalát. Ennek a menete a következő: start menü - computer (jobb klikk) - properties - advenced system settings - environment variables gomb (advanced fülön) és itt a system variables között a Path nevűt kell megkeresni és szerkeszteni. A jelenleg ott lévő sor végére pontosvesszőt kell tenni, aztán odamásolni a ruby.exe lelőhelyét - ami nálam továbbra is C:\Ruby193\bin. Ezután zárjuk be a parancssort, ha korábban megnyitva hagytuk és indítsunk egy újat, hogy frissüljön fel a fantáziája. Ekkor már működött a ruby parancs és a github-os leírást követve sikerült a Development Kit telepítése. A tálcára tett RubyMine-ba visszalépve láttam, hogy megint aktivizálta magát - gondolom észlelte, hogy meglett a hiányzó láncszem és le tudott futni a bundle install, amivel a probléma volt.

Egyáltalán nem biztos, hogy másnál is fellépnek ugyanezek a hibák. Azt nem értem igazából, hogy miért kell ez a sok kínlódás, miért nem tud valami egyből normálisan működni. Innentől kezdve aztán mehet minden rendesen, ez az IDE tényleg jónak látszik - a beállításokban jól testreszabhatjuk és komfortossá tehetjük, sőt, még az általam újabban egyre kedveltebb Zen Coding-ot is ismeri.

Az a legtöbb, hogy a RubyMine fejlesztők a honlapon a Quick Guide (gyors útmutató) alatt még írják is, hogy mielőtt elkezdesz valamit is csinálni, telepíts ezt-azt. Persze nem olvastam el, pedig olvashattam volna, így nem is lenne jogos a felháborodásom - nem is háborodok fel.

Weboldalkészítés

Wed, 01 Feb 2012 16:49:09 GMT

Ha beszélgetek valakivel és szóba kerül, hogy foglalkozom weboldalak készítésével, akkor gyakran ráugranak a témára, hogy csináljak nekik, vagy mondjam el, hogyan kell csinálni. Már ott járnak, hogy letöltöttek egy HTML-szerkesztőt, vagy MS FrontPage-et, csak nem tudják, hogy mi mivel van, illetve hogy mit kell beírni a böngészőbe, hogy az jelenjen meg, amit ők csináltak.

A weboldal készítés nem olyan nagy ördöngösség, de lehet úgy is csinálni, hogy az legyen. Minél több időt szán rá az ember, annál jobb lesz/lehet - ez persze nem minden esetben igaz, mert előfordulhat, hogy túlzásba esik az illető akár design, akár kódolás terén. Abban azonban egyet érthetünk, hogy egy weboldalnak ma már nem elég az, hogy csak HTML és CSS legyen, kell valami, ami aktívvá teszi, működésbe hozza és lehetőséget biztosít a dinamikus bővítésre. Szét lehet tehát választani a weboldalkészítést kinézetre és az azt futtató programra (motorra).

Nézzük, mik a lehetőségek

Készítesz weboldalt magadtól, nulláról

Legtöbben ezt gondolják a legkézenfekvőbbnek. Előnye, hogy a kész weboldal valószínűleg teljesen egyedi lesz és érteni biztosan fogja a készítő, hogy mi hogyan működik. A hátránya viszont, hogy rajta kívül más nem biztos, hogy érti és ami nagyobb “baj”, hogy az igényes munka rengeteg időbe telik és szaktudást igényel. Egy hatékony módja ennek a folyamatnak, ha először megrajzolja az ember a weboldalt, majd az alapján megírja a HTML és CSS fájlokat, leellenőrzi a leghasználtabb böngészőkben, hogy jól jelenik-e meg, majd php, asp.net, ruby on rails, vagy akármi mással dinamikussá és működőképessé teszi. Ezeket a lépéseket lehet keverni - például egyből HTML-t ír a készítő és menet közben dönti el, hogy mi hol legyen -, de akkor előfordulhat, hogy nem látja a végét és elfelejti, mit is akar. Ráun a készítésre és bajlódásra, folyton újrakezdi egy új ötlet alapján (tapasztalat) - persze nem minden esetben.

Letöltesz sablont és azt módosítgatod, majd készítesz hozzá egy motort

Ezt a módszert azok használják, akik nem értenek eléggé a HTML/CSS-hez, vagy nincs hozzá türelmük. Az Interneten ingyenes HTML/CSS weboldal-sablonok tömkelege fellelhető (például: Google: free html template). A letöltött sablon alá egy motort ír a készítő - ehhez szintén kell a programozási ismeret. A sablon készítői gyakran feltüntetik nevüket és esetleg elérhetőségüket a sablon alján (vagy akárhol máshol). Ezt természetesen ki lehet törölni, de határozottan nem etikus. Olyan is előfordul, hogy a készítő csak a forráskódban hagyja ott lábnyomát kommentként. Ami viszont még jó ezekben a sablonokban, hogy lehet tanulni belőlük. Ha az ember érdeklődik a HTML és CSS iránt, akkor ez egy jó tanulási lehetőség lehet: például letölt egy sablont átnézi a kódot, majd megpróbálja magától leírni és folyamatosan figyeli, hogy mi történik az egyes kódsorok beírása után. Ha elakad, ott az eredeti sablon, abból lehet lesni, vagy ellenőrizni.

Használsz egy kész motort és töltesz le hozzá sablont

Ezt szoktam leginkább ajánlani annak, aki nem foglalkozik - és nem is akar foglalkozni - HTML, CSS és programnyelvek tanulásával. Előnye, hogy gyorsan, látványos weboldalt lehet létrehozni. Ezzel viszont az jár, hogy jó esély van rá, hogy néhány másik weboldal pont úgy fog kinézni, mint a miénk - mivel azt a sablont, amit mi letöltöttünk, más is ugyanúgy letöltheti és használhatja. Erre létezik megoldás: meg lehet venni a kinézet használatának kizárólagos jogát, vagy eleve rendelésre készítettünk kinézetet - vagy akár motort is. Visszatérve az ingyenes megoldásokhoz: ott vannak a CMS-ek (Content Management System). Ezeknek előnyük, hogy szakemberek készítik őket, az esetleges hibákat folyamatosan javítják, újításokat eszközölnek és biztosítják az új verziót a használóknak. Emellett moduláris felépítésük révén tetszőlegesen bővíthetők úgynevezett pluginokkal (bővítményekkel), melyeket legtöbb esetben szintén elérhetünk a CMS honlapján. Ilyen CMS például a WordPress (kedvencem, én is ezt használom), a Drupal, a Joomla, stb. Ezek szinte mindenre jók - webáruház, blog, fórum, bemutatkozó oldal, közösségi oldal, stb. üzemeltetésére. Vannak specifikus CMS-ek, melyek adott funkció ellátására szolgálnak, például dedikált fórummotor a PHPBB, Invision Power Board (ez utóbbi fizetős).

Használsz egy kész motort és készítesz hozzá kinézetet, vagy módosítod az eredetit

Ez a nekem való megoldás :). Labilis php és Ruby on Rails tudással a fejemben leginkább a WordPress CMS-t használom. Elég sok oktató leírás (tutorial) található arról, hogy mit hogyan lehet módosítani az egyéni kinézet kialakításához. Ez is igen időigényes és kell hozzá némi programozási ismeret is. (Most a Radontastic sablont használom ezen a blogon.) Motornak ugyanazokat a CMS-eket ajánlom, mint az előző bekezdésben. Olyanra is van lehetőség, hogy egy tetsző témát letöltesz és ami nem tetszik, kiveszed belőle, vagy átteszed máshová, esetleg új dolgokat adsz hozzá. Ilyenkor is figyelni kell azonban, hogy az eredeti szerző nevét ne tüntessük el teljesen.

Na de mit kell beírni a böngészőbe, hogy megjelenjen az oldalam?

Ingyenes lehetőség

Regisztrálsz egy ingyenes tárhelyet és domaint - például az atw.hu-nál, vagy uw.hu-nál. Ilyenkor kapsz némi tárhelyet, egy adatbázist és a hozzáféréshez szükséges címeket, felhasználóneveket, jelszavakat. Például: van egy Figaro Szalon nevű fodrászatod, amihez egy bemutató honlapot készítesz, akkor beregisztrálhatod ingyen a figaroszalon.atw.hu címet. Ide FTP-n keresztül kerül fel a honlap. Azt még tudni érdemes az ingyenes tárhelyekkel kapcsolatban, hogy leggyakrabban a tulajdonosok abból tartják fenn a szolgáltatást, hogy a honlapod fölött a böngészőben reklámcsíkot jelenítenek meg.

Fizetős lehetőség

Itt jönnek be a képbe az úgynevezett hoszting cégek. Szükség van egy domain névre és tárhelyre. A domain név ez esetben már tetszőleges - az előző példánál maradva: figaroszalon.hu, .com, .eu, akár több is ugyanahhoz a weboldalhoz. A domain név regisztrálása - legtöbb esetben - nem pár perc és nem ingyenes. A .hu végződés 3000 Ft/2 év, a .com 2000 Ft/év körüli áron érhető el. A tárhelyről és a kapott szolgáltatásokról szerződést szoktak írni a hoszting céggel. Tárhelytől függően, havi 800-1000 Ft-tól (egészen havi sok ezerig) kaphatunk szolgáltatáscsomagot. A csomag árába szintén beleszól az, hogy milyen alkalmazások futtatását engedélyezi (php, perl, stb.), hányféle adatbázist biztosít, mennyi aldomaint, illetve mennyi saját postafiókot engedélyez(ami például: info@figaroszalon.hu - tehát tetszőlegesen választható, egyedi).

Az ingyenes lehetőség arra tökéletes, hogy valaki megértse, hogy mi hogyan működik. Azonban cégeknek, vagy komolyabb szándék esetében érdemes rááldozni a fizetős szolgáltatás igénybevételére. Nem mutat jól egy céges honlap tetején a reklám és az is rontja az imázst, hogy a honlap címében is van reklám (mert hát a .atw.hu-ban az “atw” bizony reklám). Ráadásul nem szólhatunk bele, hogy milyen hirdetés jelenjen meg oldalunkon, így előfordulhat, hogy pont a konkurencia hirdetése jelenik meg.

WordPress RSS kategóriák szerint

Wed, 25 Jan 2012 22:24:29 GMT

Előfordul - mint jelen esetben is -, hogy egy blog több témában publikál bejegyzéseket. Az ide tévedő olvasó esetleg érdekesnek találhat 1-1 témát, de ez az olvasó nem feltétlenül kíváncsi az összes téma összes bejegyzésére. Ha ez az olvasó gyakorta látogatja a honlapot és nem RSS olvasót használ, akkor ezzel nincs is gond, mivel oda kattint, ami számára érdekes.

Azonban, ha RSS Feed Reader-rel - azaz hírolvasóval - böngészi az újdonságokat, akkor zavaró lehet, hogy azok is megjelennek, amire amúgy egyáltalán nem is kíváncsi.

A WordPress alapból generál külön Feed-et minden kategóriának. Például, ha van egy “bútorok” kategóriánk, akkor annak az RSS csatornája a következő URL-en érhető el: http://domain.com/category/butorok. (Amennyiben közvetlen linkeket használunk az alapértelmezett ?p=20, stb. linkek helyett. Ezek beállítása: Beállítások (Settings) - Közvetlen linkek (Permalinks))

Itt, ezen a blogon is elég eltérő témákban készítek bejegyzéseket, ezért jártam utána ezeknek. Létezik egy plugin: Category Specific RSS feed Subscription néven. Ezt próbáltam először, de feltűnt, hogy az általa generált linkek a plugin kikapcsolt állapotában is működnek, így magam is elkészíthetek egy “Kategóriák szerinti RSS” menüt. Ehhez az admin felületen kell a Megjelenés (Appearance) - Menük (Menus) ponthoz navigálni magunkat, itt létrehozni egy új egyéni menüt és egyenként beírva az URL-eket már el is készítettük. Ezek után annyi csak a feladat, hogy a Widgetek menüben az “Egyéni menü” (Custom menu) névre hallgató widgetet a kívánt helyre mozgatjuk (például oldalsávra), kiválasztjuk a kis listában az előbb elkészített egyéni menüt és mentjük.

A korábban említett plugin annyival tudott többet ennél, hogy egy RSS ikont tett a menüpontok elé, de cserébe alul a készítő a saját weboldalára mutató linket tett. Ráadásul a plugin beállításainál megadott kategóriaelnevezésekre és sorrendre nem is figyel.

Később feltehetőleg kitalálok valamilyen színesítést, hogy valahol ebben a boxban jelenjen meg egy RSS ikon. Lehet a megoldás nem is az egyéni menü használata lesz, hanem egyszerű szöveg (HTML kód) hozzáadása az oldalsávhoz.

Maga az RSS egyébként az RDF Site Summary-nek, vagy a Really Simple Syndication-nek a rövidítése. Akit érdekel, hogy pontosan mi is az és hogyan működik, az a Wikipédián talál róla leírást.

SiteBuild++

Mon, 23 Jan 2012 21:15:28 GMT

Többnyire sitebuilddel foglalkozom, de bele-bele fogok az ezt megelőző - grafikai, tervezési - és az ezt követő programozási munkálatokba is.

Egy weboldal elkészítése alapesetben a következő lépésekből áll:

Megrajzolják a weboldalt egy grafikus programmal
A rajzból megcsinálják a HTML, CSS és JavaScript fájlokat tartalmazó vázat
A vázat működőképessé és aktívvá teszik valamilyen rendszerrel (pl. PHP-val, ASP.net-tel, Ruby-val, stb.)

Jelen felsorolásban az egyszerűség kedvéért kihagytam a weboldal megrajzolását megelőző folyamatokat, mint például megrendelői igényfelmérés, tartalom szerinti átgondolás, stb. Ezekre külön oda kell figyelni, hogy ha megrendelésre dolgozik valaki, akkor pontosan azt kell kapnia a vevőnek, amit szeretne - esetleg annál többet, de kevesebbet nem. Ez a cégszerű sikeres működés egyik alapszabálya.

Maga a sitebuilding (nyersfordításban: oldalépítés) az a folyamat, ahol egy weboldalt előkészítenek ahhoz, hogy egy programozó működőképessé tegye. Hasonlóképp: autógyártásnál egy tervező megrajzol egy autót, egy csapat megalkotja a karosszériát, egy másik csapat pedig legyártja a motort és beleteszi a vázba. A sitebuilder az, aki megalkotja a weboldal karosszériáját.

Munkaeszközök

A sitebuild abból a szempontból szerencsés, hogy nem igényel komoly befektetést, gyakorlatilag egy notepaddel is el lehet készíteni. Vannak az úgynevezett WYSIWYG (What you see is what you get - kapod, amit látsz) programok, amikkel a készülő weboldal megjelenési alakját folyamatosan látjuk. Ilyen (funkcióval is rendelkezik) a Dreamweaver, a Coda, ingyenesek közül a régen NVU, most Kompozer, stb. Ezek kezelése (is) tanulást igényel. Én nemes egyszerűséggel NotePad++-t használok, itt csak a kódot látom és kell nyomnom egy CTRL+S, ALT+Tab, CTRL+R kombinációt ahhoz, hogy lássam a munkám eredményét, de nekem ez jön be.

Legtöbb esetben a grafikai állomány megnyitásához jól jön egy Photoshop, ami megoldás, de ingyenes megoldásnak ott a GIMP.

Kell még néhány böngésző is, a legnépszerűbbeket mindenképpen érdemes feltelepíteni: Firefox, Chrome, Safari, Internet Explorer, Opera. Az sem árt - ha a rendszer engedi -, ha a népszerű böngészők több, még a felhasználók körében fellelhető verziót is feltelepítünk, hogy lássuk, hogyan jelenik meg azokban a weboldal. Az Internet Explorer 9 esetében például ez már beépített eszköz, itt kapcsolgathatjuk a kompatibilitást.

Ami még nagyon hasznos - főleg a tesztelésnél- , az a böngészők fejlesztői eszköztára. Legtöbb böngészőben megtalálható. Számomra a leggyakrabban használt a FireBug, ami a Firefox kiegészítője.

Előfordul, hogy egy kész, már php alapú rendszer (pl. Wordpress) témáját kell módosítani. Ez esetben érdemes feltelepíteni az adott tartalomkezelőt a localhostra. Ehhez persze kell néhány dolog (Apache, SQL) - a XAMPP, vagy WAMP tartalmaz minden szükséges eszközt, használata ilyenkor megkönnyíti a munkát, mivel nem kell mindig FTP-vel feltöltögetni a frissített fájlokat.

Állományok

HTML: HyperText Markup Language. Ezt úgy tanultam még anno, hogy ez nem programnyelv, hanem csak jelölőnyelv (mint a nevében is benne van). Itt csak megjelenést írunk le, hogy mi mit követ és mit tartalmaz. Adhatunk meg formázási tulajdonságokat is, de ezt elegánsabb külön állományban megadni. Legújabb verziója az 5.

CSS: Cascading Style Sheets. Kaszkádolt stíluslapok. Ezek írhatóak a HTML-be közvetlenül, vagy külön .css kiterjesztésű fájlba - ez utóbbi esetben szükséges hivatkozni a helyére a HTML kódon belül. A stíluslapokban kerülnek definiálásra az oldalon helyezkedő elemek tulajdonságai, mint például: szín, méret, elhelyezkedés, stb. Legújabb verziója a 3.

JS: JavaScript. Ezekkel az oldal aktívvá tehető, dinamikusan tölthető be a tartalom, optimalizálható az oldal betöltése, különböző megjelenítési mód eszközölhető a különböző böngészőkhöz, stb. Ez már programozás. Objektumorientált, hasonlít a C-re.

jQuery: Az egyik legnépszerűbb JavaScript library (könyvtár). Ez azt jelenti, hogy letölthető a jQuery honlapjáról a legújabb, aktuális jquery.js, aminek használatával könnyen és gyorsan lehet látványos elemekkel (pl.: effektekkel, slideshow-val) gazdagítani az oldalt. A jquery.js gyakorlatilag egy JavaScript fájl, amiben egy fejlesztőcsoport előre megírt sok “funkciót”, amit mi egyszerűsítve meghívhatunk a mi weboldalunkra. Ezáltal egyedi nyelvezete van, de elég logikus, így gyorsan és könnyen tanulható.

Ezeket használom én. Nem említettem, de van még rengeteg egyéb is. Ha majd azokkal is foglalkozok, azokról is írok.

TabletPC körkép

Sun, 22 Jan 2012 15:40:49 GMT

A tabletPC piac egy feltörekvő piac, újabb és újabb szereplőkkel, ahol mindenki jobbat vagy többet akar nyújtani a fogyasztónak azonos áron, vagy azonos hardverrel rendelkező eszközt adna el alacsonyabb áron. Ennek a versenynek köszönhetően az árak egyre lejjebb mennek.

Másrészt, egy új, fejlettebb tablet megjelenése a régi tablet árát lejjebb nyomja. Pl.: az Apple kb $6-800-ért adta az ipad-et, de mikor megjelent az ipad2, akkor azt adták annyiért, így a raktáron maradt ipadeket nyilván olcsóbban adták, mint az újat.

Mivel látható, hogy a fejlődés nagy ütemben történik, így tudható, hogy a most megvett tablet hamar elévültnek számíthat, ennek megfelelően az értéke is folyamatosan csökken – akárcsak a telefonoknál.

Ez a fejlődés nem áll meg egyhamar, szóval azt várni, hogy „na mikor vegyek, amikor nem jelenik meg új”, hiba. Kivéve, ha egy jelentősen új termék jelenik meg, ami már nem tablet, hanem még annál is könnyebb, gyorsabb, menőbb. Ilyenre volt példa a laptopok térnyerése az asztali számítógépekkel szemben. Marketing szempontból a termékeknek meghatározható életgörbéje van, így: bevezetés, növekedés, érettség, hanyatlás. A bevezetési szakaszon szerintem már túljutottunk az első ipad megjelenésével. Nehéz meghatározni, de úgy gondolom még a növekedési szakaszban van a termék, tehát még nem érte el az érettség szintjét. Egyre több a vásárló, már nem csak az innovátorok vesznek tabletet, hanem a korai elfogadók is – de még közel sem terjedt el olyan széles körben, mint a laptop vagy a mobiltelefon.

Az árat a gyárakat érő természeti katasztrófák, a szabadalmi perek és a gyárak dolgozói sztrájkjai növelhetik, de ez nem gyakori, inkább a túlzott raktárkészlet a jellemző, mint a hiány.

Ezek tükrében mindenki mérlegelheti, hogy mennyire van neki szüksége tabletre. Az idő a vásárlónak dolgozik. Külföldön olcsóbb. Íme a jelenleg népszerűek közül néhány (szubjektív véleménnyel):

3g-s

SIM-kártya foglalattal rendelkeznek, így ha beleteszünk egy Internet-előfizetéssel rendelkező SIM-et, akkor ahol van térerő, tudunk netezni.

Motorola Xoom 3G

előny: ilyen van nekem, gyors, jön rá frissítés, sokáig bírja az akkumulátor, szép kép, 32GB belső tárhely + bővíthető microSD-vel hátrány: viszonylag nehéz, nem tölthető USB-ről ár: 116 500 Ft

Motorola Xoom 2

előny: adnak hozzá Motorola Stylus-t (ceruza), 200 mhz-el nagyobb órajelű processzor az elődhöz képest, strapabíró Gorilla Glass kijelző hátrány: nagyon drága ahhoz képest, hogy nem sokkal több az 1. xoom-nál. ár: 174 670 Ft

Archos 101 G9

előny: felszereltséghez képest kedvező ár, ua felszereltség, mint a xoomnak, bővíthető tárhely (alapból 8 gb) hátrány: kevésbé ismert, új gyártó ár: 94 500 Ft

Apple iPad 2 16Gb 3G

előny: gyors, nagyon össze van rakva, könnyű, vékony, menő és kényelmes kezelés hátrány: nem lehet rá tört alkalmazást telepíteni, rátölteni dolgokat iTunessal lehet csak (azt hiszem) ár: 141 990 Ft

Samsung Galaxy Tab 10.1 16Gb

előny: könnyű és vékony, szokásos jó hardver hátrány: nincs USB port és SD-kártya bővítési lehetőség ár: 123 650 Ft

Wi-Fi only

Csak akkor tudunk rajta netezni, ha van a közelben Wi-Fi hotspot, amihez csatlakozhatunk.

Asus Transformer TF101 16Gb

előny: lehet hozzá dokkolható billentyűzetet venni, jól bírja az akkumulátor, könnyű, jó anyagból készült, gyors hátrány: drága, ASUS magyar supportot nem nagyon dicsérik ár: 189 900 Ft

Toshiba AT100

előny: szinte ugyanaz a hardver, mint a xoomnak ár: 129 899 Ft

Apple iPad 2 16 Gb WiFi-only

Amazon Kindle Fire

előny: hardvereihez képest igen jó árban van hátrány: szerintem a 7 colos kijelző kicsi, néhány ember szerint kényelmetlen helyen van a gombja ár: 74 500 Ft Magyarországon, külföldön $199

(az árak Google-ben, árukereső.hu-n, árgépen talált magyar boltok árai)

Váratnak magukra, de ígéretesek:

Apple iPad 3
Google Nexus Tablet
Windows 8 megjelenése

Android, iOS, Windows 8

A tableteken operációs rendszer fut. A címben szereplők közül az első kettő terjedt el. A legnépszerűbb tableteken – ami az ipad, azokon az Apple iOS-e fut. Ezeknek előnye, hogy nagyon gyorsak, szerintem ritkábban fagynak, mivel minden ipad egyforma, ezért az alkalmazásoknál nincs felbontás- és kompatibilitás-probléma. Kezelésükre ötletes gesztusok használhatók, például az alkalmazásváltáshoz 4 ujjal a kijelzőt érintve egyszerűen lapozhatunk, valamint összezúzó mozdulattal bezárhatjuk. Hátrányuk (?), hogy csak az appStore-ból letöltött alkalmazások telepíthetők rá, tehát az alkalmazást meg kell venni mindenkinek. Ehhez szerintem (aljas módon) nincsenek hozzászokva az emberek. Egyébként az alkalmazások nem olyan drágák, 1-10 dollárba kerülnek általában, de rengeteg ingyenes változat van. Másik hátrány, hogy nem támogat widgeteket, így nem tehető ki a kezdőképernyőre kis képecske, időjárás-jelentés, bejövő levelek előnézete, stb.

Az Android a Google-é, az pénzeli, birtokolja. A sokféle kijelző eltérő mérete miatt az alkalmazások korábban nem, vagy csak rosszul jelentek meg. Erre a fejlesztők már a terjedés miatt jobban odafigyelnek, így ez a probléma háttérbe szorul. Mivel az operációs rendszer és a hardver gyártója nem ugyanaz, így a frissítések általában késnek, egy idő után pedig elmaradnak. Viszont az Androidos tabletek olcsóbbak, lehet rájuk widgeteket pakolni, telepíteni rá mindenféle kétes eredetű alkalmazást. Magam is ezt a megoldást választottam. Ráadásul nagyon jól összeszinkronizálható PC-vel és androidos telefonnal.

A Windows 8 még meg sem jelent, de már ígérgetik. A Microsoft újabbak kissé szét van esve, több bevétele van az Androidért kapott licenszdíjakból, mint a saját mobiltelefon operációs rendszeréből (Windows Mobile 7). Jósolják, hogy a Windows 8 is felforgatja majd a tablet piacot, de ha ez olyan mértékű felforgatás lesz, mint annak idején a Windows Phone 7-tel történő mobilpiac felforgatás volt, akkor nem kell nagy bummra számítani.

További operációs rendszerek a HP által használt webOS, vagy a RIM (Blackberry gyártó) QNX-alapú rendszere, de az ezeket futtató készülékek (HP Touch és RIM PlayBook) gyakorlatilag csak veszteséget hoztak a gyártóknak – a korábban aranyárban meghirdetett tableteket most fillérekért próbálják kiszórni a raktárból.