序言

最近买了个树莓派想学习一下 Linux,所以去淘宝买了一些硬件就尝试起来,买个树莓派板子,一个壳子,一个电源线,如果想连显示器,就买转换头,树莓派3带 HDMI接口,一个SD卡,一个读卡器。
至于为什么想起来要买这个,其实是我想学些linux相关,但公司环境也不好用来自己学习用,怕会搞坏环境,于是想自己搭一个可以随时访问的自己的环境,经过一番搜索就找到了它,价格也便宜,于是就开始了。
我买的最新出的树莓派3。

遇到的问题

想要启动树莓派,现在硬件是齐全了,那要怎么安装系统呢,问题来了树莓派如何安装系统

背景知识

Raspberry Pi,缩写RPi或者RasPi,中文译名为“树莓派”,是一个信用卡大小的、基于Linux的“卡片电脑”(Single-board Computer,单板机),是为学生计算机编程教育而设计,由英国剑桥某实验室历经6年的研制,于 2012年2月29日公开发布并接受预定。负责Raspberry P(树莓派)i这个项目运作的是树莓派基金会(Raspberry Pi Foundation),该基金会主任是Eben Upton(埃本·阿普顿),在媒体前有着非常高的曝光率。
探究Raspberry Pi的命名,一种广为接受的说法是:“Raspberry(树莓)”来源于剑桥以水果命名的老传统,”Pi”则为Python的缩写,意为Python将做为Raspberry Pi应用主要编程语言之一。
2012年3月,英国剑桥大学埃本·阿普顿(Eben Epton)正式发售世界上最小的台式机,又称卡片式电脑,外形只有信用卡大小,却具有电脑的所有基本功能,这就是Raspberry Pi电脑板,中文译名”树莓派”!这一基金会以提升学校计算机科学及相关学科的教育,让计算机变得有趣为宗旨。基金会期望这 一款电脑无论是在发展中国家还是在发达国家,会有更多的其它应用不断被开发出来,并应用到更多领域。

分析问题

现在的我其实树莓派硬件等各个方面基本不懂,软件也是以前碰过的半吊子的Linux,顶多装装Ubuntu,但都没怎么使用过。
我要做的就是先安装系统,让树莓派启动起来。
既然都不了解,就先看比人的教程,树莓派要先将SD中写入系统,然后安装在树莓派上,就可以启动了,看起来很简单。

问题解决过程

  1. 我电脑可以读SD卡,然后用转换器,把SD卡插到电脑上,我使用SDFormatter格式化 SD卡
  2. 然后用在官网上下载好的系统,这个系统我选择官网的Raspbian,由于了解不多,所以用官方最简单上手的。接着使用工具win32 Disk Imager把img文件写到sd卡上。(我电脑是win7,据说32G以上sdka不能用这个工具)
  3. 将SD卡插入到树莓派上那个sd卡插槽,然后插上电源即可。
  4. 现在这个阶段,如果正常的话会看到两个灯,一个红灯常亮,一个会闪烁,黄红切换。如果不用其他外设,暂时只能看到这些,并不能知道系统是不是启动正常,如果又显示器,插上显示器可以看到,或者使用串口(这个略复杂,我暂时不清楚使用方法),后面我会继续尝试使用,来确实是否安装系统成功。这次的应该是试验成功的步骤,下篇教程继续。

目标
为了介绍spring boot的简单入门,而且讲明白为什么要使用它,它的特点。
手段
通过介绍spring boot的发展历史,诞生当时的历史现状,诞生的原因,发展,来说明
资料
官方简介:
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”. We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.

Features

  • Create stand-alone Spring applications
  • Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
  • Provide opinionated ‘starter’ POMs to simplify your Maven configuration
  • Automatically configure Spring whenever possible
  • Provide production-ready features such as metrics, health checks and externalized configuration
  • Absolutely no code generation and no requirement for XML configuration

Spring的发展情况

When Spring 1.0 hit the scene, it completely changed how we develop enterprise Java applications. Spring dependency injection and declarative transactions meant no more tight coupling of components and no more heavyweight EJB s. It couldn’t get any better.

With Spring 2.0 we could use custom XML namespaces for configuration, making Spring itself even easier to use with smaller and easier to understand configuration files. It couldn’t get any better.

Spring 2.5 gave us a much more elegant annotation-oriented dependency-injection model with the @Component and @Autowired annotations, as well as an annotation-oriented Spring MVC programming model. No more explicit declaration of application components, and no more subclassing one of several base controller classes. It couldn’t get any better.

Then with Spring 3.0 we were given a new Java-based configuration alternative to XML that was improved further in Spring 3.1 with a variety of @Enable -prefixed annotations. For the first time, it become realistic to write a complete Spring application with no XML configuration whatsoever. It couldn’t get any better.

Spring 4.0 unleashed support for conditional configuration, where runtime decisions would determine which configuration would be used and which would be ignored based on the application’s classpath, environment, and other factors. We no longer needed to write scripts to make those decisions at build time and pick which configuration should be included in the deployment. How could it possibly get any better?

spring boot起源

Spring的jira上提的需求,揭示了spring boot的起源
https://jira.spring.io/browse/SPR-9888
描述:
As the enterprise development landscape grows more diverse the simpler the application framework the more likely developers are to adopt the framework. Developers with existing knowledge of previously common frameworks like the Servlet container are becoming more rare. Spring’s dependence on frameworks and containers outside of Spring’s component model increases the learning curve of new developers attempting to create and maintain spring web applications.
Traditionally Spring web applications have been embedded in a servlet container. This was useful in the past when the majority of enterprise applications ran in and depended on the servlet container for deployment and configuration. However, a servlet container comes with learning curve that we cannot assume new developers will have already overcome. The learning curve includes things such as:
web.xml and other Servlet oriented configuration concepts
.war directory structure
Container implementation specific items (e.g. ports, thread pools, etc.)
Complex Classloading hierarchies
Monitoring and management facilities configured outside of the application
Logging facilities
Configuration of application context roots
So forth
All of the above items are configured in inconsistent non-unified ways requiring a development team to learn these for the container their using in addition to Spring’s own configuration model.
I think that Spring’s web application architecture can be significantly simplified if it were to provided tools and a reference architecture that leveraged the Spring component and configuration model from top to bottom. Embedding and unifying the configuration of those common web container services within a Spring Container bootstrapped from a simple main() method.
Though there are many frameworks and platforms today that no longer require a container I think inspiration can be drawn most from DropWizard (http://dropwizard.codahale.com/).
Another project I’ve seen inspired by DropWizard but leveraging Spring is HalfPipe (https://github.com/32degrees/halfpipe). Though I don’t think HalfPipe goes far enough. I think to truly provide simplification the entire architecture, wherever reasonable, must be embedded within the Spring container rather than without. Though it does have several other interesting ideas.
I believe that a Spring driven containerless web application architecture could provide benefits like:
Provide a single unified component model requiring no knowledge of the Servlet Component models.
Unified configuration of everything allowing developers to only have to learn one Spring configuration model for both component and app configuration.
Execution from a void main will simplify application startup and shutdown.
A much simpler pure java classloading hierarchy.
Simpler development tooling. Instead of needing a complex IDE to construct a war and deploy it to a dev container simply execute the applications Main class.
For such an architecture to be successful this architecture will also need new and simple ways to configure common Spring tools, such as Spring MVC and Spring Security, that have traditionally been configured through the servlet container.
To accomplish this simplification I don’t think Spring would need to create a brand new http engine. It could simply utilize an embedded servlet container like Jetty. Though it would need to abstract away as much configuration as possible.
I think a reference app would also be unnecessary to set an example of how to structure, develop and configure such an application in a pure spring manner.
翻译描述:
开发人员越来越多的采用更简单的框架。会以前通用框架的相关知识,像Servlet容器的开发者越来越少了,Spring应用以来容器,提高了新的开发者尝试创建和使用spring web 应用。
传统spring web应用嵌入在servlet容器中。大多数企业应用的部署和配置,依赖和运行在servlet容器上,这在过去是有效的。
然而,一个servlet容器自带的学习曲线,我们不能承担新的开发者已经克服。
学习曲线包含:

  1. web.xml和其他 Servlet面向配置的概念
  2. .war目录结构
  3. 容器内具体的项目(端口,线程池等)
  4. 复杂的类加载结构
  5. 监控和管理设施要配置的应用程序之外
  6. 日志设施
  7. 应用上下文根配置
    8.等等
    上述所有项目都在要求开发团队学习这些他们除了使用Spring的自己的配置模型容器不一致的不统一配置方式。

我认为Spring的web应用程序架构可以显著简化,如果它是提供工具和参考架构 从上到下的连通Spring组件和配置模型。嵌入和统一的配置 这些共同Web容器服务的配置 可以从Spring容器一个简单的main()方法中的。
我相信,一个Spring驱动无容器的Web应用架构可以提供下列好处:

  1. 提供一个统一的组件模型,无需在Servlet组件模型的知识
  2. 人的一切都允许开发统一的配置,只需要学习一种Spring配置模型为组件和应用配置。
  3. 用从一个空的main简化应用程序的启动和关闭。
  4. 一个更简单的纯Java类加载层次
  5. 更简单的开发工具。而不是需要一个复杂的IDE来构建一个战争并将其部署到一个开发容器只需执行应用程序主类。

对于这样的体系结构,为了成功这个架构也需要新的和简单的方式来配置公共Spring工具,如Spring MVC和Spring Security,即传统上一直通过servlet容器构造。
要做到这一点简单化,我不认为Spring需要创建一个全新的HTTP引擎。它可以简单地利用像Jetty一个嵌入式servlet容器。尽管这将需要抽象掉尽可能多的配置成为可能。
我想引用的应用程序也将是不需要设置如何构建一个例子,开发和配置在纯Spring的方式这样的应用程序。

可以看出,spring为了实现无容器依赖,减小开发者的学习曲线,更快的开发web应用,开发出了spring boot,spring boot就是为了简化web开发体验。

注解(也被称为元数据)为我们在代码中添加信息提供一种形式化的方法,使我们可以在稍后某个时刻非常方便地使用这些数据

Java中常见注解

@Override :表示当前的方法定义将覆盖超类中的方法。如果有错误,编译器将发出错误提示。
@Deprescated:被弃用的方法
@SuppressWarnings:关闭不当的编译器警告信息。

注解的分类

按照运行机制分:源码注解,编译时注解,运行时注解
按照来源分:来自JDK的注解,来着第三方的注解,我们自己定义注解

自定义注解

定义注解

1
2
3
4
5
6
7
8
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface UseCase {
public int id();
public String description() default "no description";
}

使用#interface声明注解,成员以无参无异常方式声明,可以用default为成员指定默认值,成员类型是受限的,合法的类型包括原始类型及String,Class,Annotation,Enumeration以及以上类型的数组。如果注解只有一个成员,则成员名必须取名为value(),在使用时可以忽略成员名和赋值号。

元注解


@Target : 表示该注解可以用于什么地方。ElementType参数包括:
CONSTRUCTOR:构造器的声明
FIELD:域声明(包括enum实例)
LOCAL_VARIABLE:局部变量声明
METHOD:方法声明
PACKAGE:包声明
PARAMETER:参数声明
TYPE:类、接口(包括注解类型)或enum声明


@Retention : 表示需要在什么级别保存该注解信息。可选的RetentionPolicy参数包括
SOURCE:注解将被编译器丢弃
CLASS:注解在class文件中可用,但会被VM丢弃
RUNTIME:VM将在运行期也保留注解,因此可以通过反射机制读取注解的信息。


@Documented : 将此注解包含在Javadoc中


@Inherited : 允许子类继承父类中的注解

使用注解
@<注解名>(<成员名1>=<成员值1>,<成员名2>=<成员值2>,…)

1
2
3
4
@Description(desc="I am eyeColor",author="Mooc boy",age=18)
public Sring eyeColor(){
return "red";
}

编写注解处理器
通过反射获取类、函数或成员上的运行时注解信息,从而实现动态控制程序运行的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class UseCaseTracker {
public static void trackUseCases(List<Integer> useCases,Class<?> cl){
for(Method m : cl.getDeclaredMethods()){
UseCase uc = m.getAnnotation(UseCase.class);
if(uc!=null){
System.out.println("Found use case:"+uc.id()+" "+uc.description());
useCases.remove(new Integer(uc.id()));
}
}
for(int i : useCases){
System.out.println("Warning: Missing use case:"+i);
}
}
public static void main(String[] args){
ArrayList<Integer> useCases = new ArrayList<Integer>();
Collections.addAll(useCases, 47,48,49,50);
trackUseCases(useCases, PasswordUtils.class);
}
}

注解定义

1
2
3
4
5
6
7
8
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface UseCase {
public int id();
public String description() default "no description";
}

在github上搭个博客前后也花了点时间,这周总算是搞定了,可以开始一次全新的旅程了。以前的博客写的拖拖拉拉,想把东西总结好了再写出了,然后就是一直没总结,一直不敢下笔写,效率太低。互联网时代这种方式已经跟不上节奏了,所以今天开始进行快速学习。

我是想总结一个技能树,不断补充枝叶,希望最后能结出一些果实。

闲话不多说了,旅程开始!