Interesantes consejos para optimizar nuestra base de datos en nuestras aplicaciones:
Aunque parezca mentira, no siempre es necesario una base de datos relacional. Existen alternativas como memcache, base de datos documentales o de clave-valor.
No uses la BD para almacenar contenidos: imágenes o documentos en BLOB.
Usa campos numéricos y autoincrementales para los índices primarios, para así tener un acceso rápido al registro, ya que inserts, updates y selects dependen mucho de este índice.
Analiza correctamente el uso de índices al igual que haces un análisis detallado de la estructura de la BD.
Realiza queries sencillas, en las que solo debes recuperar los campos que necesites y evitar el uso de LIKE y NOT IN
OpenCart es una aplicación para venta online (el típico carrito de la compra) realizado en PHP5 y MySQL.
Es fácil de instalar y de administrar y posee casi todas las opciones que un e-commerce necesita: pago, shiping, artículos, clientes, paypal… OpenCart
Vía / SmashingApps
Opera Developer Console es una herramienta realizada en Javascript que nos ayuda a inspeccionar y analizar durante el desarrollo o el debug diversos aspectos de las páginas web.
La herramienta dispone de varias pestañas que nos muestra la informacion sobre:
DOM: nos muestra un árbol de nodos, permitiendo seleccionar los elementos mediante los nodos o los nodos mediante la selección en el documento. A parte nos permite buscar entre los nodos, eliminar nodos, ver sus caracterÃsticas y filtrar los nodos vacios.
JS: un inspector Javascript que nos da la posibilidad de ver los objetos y sus atributos y buscar entre ellos.
CSS: gracias a esta pestaña podemos obtener información de cada hoja de estilos, pudiendo activarlas o desactivarlas, editarlas y exportarlas.
Con algunos dÃas de retraso llega la versión 2.0.6 beta 1 del popular sistema de publicación WordPress. De su anuncio se extrae que el nuevo paquete intenta resolver los problemas que algunos usuarios han tenido con la anterior versión 2.0.5, incluido
Diseñar una base de datos no es algo sencillo y sà muy importante, ya que un mal diseño conlleva dificultades para desarrollar la aplicación o una aplicación compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo.
Ignorar la normalización: la normalización es fundamental para un buen rendimiento y una sencilla programación.
Nomenclatura no estándar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseño.
Falta de documentación: esto es una constante en todo el mundo de la programación, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que tú.
Una tabla que agrupa a muchas: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor meterlo todo en una única tabla.
No usar las caracterÃsticas de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaños de los campos y claves secundarias en el diseño para obtener una mejor integridad de datos.
Falta de pruebas: algo para mà muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitará la aplicación. Comprobar el tiempo de ejecución de las sentencias para añadir Ãndices, etc…
Como se puede ver, existen dos scripts dentro de npm: build que compila el js y extrae los CSS, y dev, que arranca el servidor de webpack habilitando HMR (🎶 ¡ya no puedo vivir sin él! 🎶).
Ambas configuraciones de webpack usan un script en común (webpack.config.common.js):
const webpack = require( 'webpack' );
const path = require( 'path' );
// Carga los ficheros .vueconst VueLoaderPlugin = require( 'vue-loader/lib/plugin' );
// Configura stylelintconst StyleLintPlugin = require( 'stylelint-webpack-plugin' );
// Para obtener un path para los aliasfunctionresolve( dir ) {
return path.join( __dirname, '.', dir );
}
module.exports = {
mode: 'production',
// Fichero inicial del proyecto
entry: './js/main.js',
// Fichero final para incluir
output: {
filename: 'js/main.js',
publicPath: '/dist/',
},
module: {
// Reglas para los ficheros
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
},
{
test: /\.vue$/,
loader: 'vue-loader',
},
{
test: /\.css$/,
use: [
'css-loader',
'sass-loader',
],
},
],
},
plugins: [
new webpack.HotModuleReplacementPlugin(),
new VueLoaderPlugin(),
new StyleLintPlugin( {
files: [ '**/*.{vue,htm,html,css,sss,less,scss,sass}' ],
} ),
],
resolve: {
extensions: [ '.js', '.vue', '.json' ],
alias: {
'@': resolve( '' ),
},
},
};
El frontend se gestiona desde el fichero main.js, que inicializará Vue y añadirá el componente principal:
import Vue from 'vue';
import Buefy from 'buefy';
import'buefy/dist/buefy.css';
import App from './components/App.vue';
import'@/assets/scss/main.scss';
Vue.use( Buefy );
new Vue( {
el: '#app',
components: {
App,
},
render: ( c ) => c( 'app' ),
} );
// accept replacement modulesif ( module.hot ) {
module.hot.accept();
}
Y ya por último el componente App.vue, que muestra simplemente un poco de HTML
El caso es que uno de los widgets que no validan XHTML es el de YouTube. Asà es que he escrito un pequeño plugin de WordPress, al que he llamado StarTrekIntro, para generar el código validable de los vÃdeos de YouTube.