关于本人帖子的一些解释

从标题上看出我写的帖子相关的问题的最终结果

所以,我的帖子的标题,一般都会加上前缀,且不同的前缀,表示不同含义:

且尽量达到自解释(self explainable)的效果。

即:

  • 【已解决】:表示遇到了问题,经过折腾,最终解决了所以一般同时也会整理
  • 【未解决】:表示尝试去解决某个问题,但是最终没解决

请注意:个别帖子,可能是:实际上该问题后来解决了,但是由于忘了或者时间关系,未能及时更新该贴而已

  • 【记录】:表示只是记录过程 -> 至于折腾某种东西最终的解决,是否达到了预期目标,是否解决了问题,都都是未知的

只不过:绝大部分,大于90%的情况下,都已经搞定了问题而已

当然:个别的东西,也的确可能是最终还是没搞定的,这个也是可能的

  • 【整理】:针对某个领域或知识点,去做总结

大多数时候,都是对于某技术有了一定的折腾,才最后再去整理总结的

也有个别的内容,先整理总结(记录一些参考资料等等),后再折腾的

同理,也有个别的是:边折腾,边总结的(及时记录所学心得和领域)

为何非要一遍折腾,一边记录?

如果你也是边折腾技术边记录,就会明白:

其边折腾边记录,记录处理问题的过程,思路,所要消耗的精力

远远大于,直接记录问题的答案,直接给出解决办法,所要消耗的精力。

而之所以边折腾边记录的原因主要有两方面:

1.我写帖子的目的在于授人以渔,而不是授人鱼

“一是:在技术方面:死磕自己,方便大家”和“二是:希望能达到:不仅能授人鱼还能授人以渔”

而如果想要达到授人以渔的话,则很明显:

直接告诉别人某个特定问题的答案和解决方案,是不行的,

记录处理问题的思路和过程,才可能做到:

有心人,看了后,明白问题答案背后的思路

才可能更好的:

总结问题经验,避免以后再犯

搞懂某个东西(技术点),实现举一反三,搞定今后可能出现的类似问题

总之:

记录折腾的过程,才能给那些用心看的读者,去实现授人以渔的效果

2.边折腾边记录,容易记录折腾过程所设计的内容,以便后查

毕竟,写帖子,除了给别人看,

偶尔自己为己所用:

自己后来折腾某个东西,甚至遇到同样的,之前已经于到的问题,再次回顾,看看之前如何解决的。

总之:

记录折腾过程,为了有时候,方便自己查阅和参考之前已有的折腾

为何不直接把结论写在帖子最开始?

很明显:

把问题的解决办法,结论,写在帖子最后,是上面的:

边折腾,边记录的顺其自然的做法:

最后才知道问题是否有解决办法

当然,理论上,也是可以把结论写在帖子最开始的:

折腾期间,是边折腾边记录

但是问题最终搞定后

可以手动的,把结论移到帖子开始,对于此想法:之前就想过

但是还是觉得放在最后,对于这个帖子,从逻辑上更通顺:先有折腾,后有结论

而且我个人是觉得:作为我的帖子的读者,连,去花点时间,读我的,花了大量精力,去记录的折腾过程,都懒得花的话,而直接就想要答案的。那么:

心情是可以理解的,但还是希望,有心的读者,可以从我折腾的过程,可以学到解决问题的思路,而不是只是要个答案 ,而对于,个别情况下,只是要答案,不想要过程,也是完全可以理解的,那就烦请自己拖到帖子底部,去看答案。

结论

1.如果你是用心的读者

很明显可以从很多帖子的折腾过程中,了解我是如何处理和解决问题的,

自然可以参考:

学到如何学会利用网络资源,解决自己的问题

如何慢慢的学习,做到做事情的举一反三,触类旁通

如何真正的,把别人(我)的东西,变成你自己的

这样以后你再遇到类似问题,就可以靠自己搞定

而不是靠参考别人(我的)的内容了。

2.如果你看到帖子中已经写了

【已解决】,那么自然可以找到问题的解决办法,而且甚至有多种解决方案的;

【未解决】,暂时没搞定问题,只有折腾过程供你参考了;

【记录】,不要指望,一定可以获得问题的答案,虽然大部分情况下,都是可以找到你所要的问题的答案,但是也存在个别情况下,没有达到最终解决事情的目的。注:但是期间折腾经过,也还是有一定参考价值的。

【整理】,可以了解和参考一些我整理和总结的内容,往往是有些技巧,心得,体会之类,供你参考的。

3.希望

以后,其他读者,能清楚我写帖子的逻辑和思路,更认真的看帖,能看帖之前,认真的思考

时间: 2024-12-23 14:10:42

关于本人帖子的一些解释的相关文章

NDK在windows下的开发环境搭建及开发过程

在Android应用的开发project中.无论是游戏还是普通应用.都时常会用到.so即动态链接库,关于.so是什么玩意儿,有什么优点.这个大家能够在网上查一下,本人不做过多解释. .so本是linux下的文件类型,所以编译.so必需要在linux环境下,那么怎样在win下进行编译呢?随便在网上搜下,教程也是五花八门,不清不楚,没有一定功底,即便看着教程到最后预计还是功败垂成,更别说刚開始学习的人,看了保证头晕眼花,本人也是依据网上的一些样例.总结了一个个人觉得还算比較简单的一个.so的编译方法

hdu 4859 海岸线 Bestcoder Round 1

http://acm.hdu.edu.cn/showproblem.php?pid=4859 题目大意: 在一个矩形周围都是海,这个矩形中有陆地,深海和浅海.浅海是可以填成陆地的. 求最多有多少条方格线满足两侧分别是海洋和陆地 这道题很神 首先考虑一下,什么情况下能够对答案做出贡献 就是相邻的两块不一样的时候 这样我们可以建立最小割模型,可是都说是最小割了 无法求出最大的不相同的东西 所以我们考虑转化,用总的配对数目 - 最小的相同的对数 至于最小的相同的对数怎么算呢? 我们考虑这样的构造方法:

CentOS7 配置LAMP

这两天要带新同事.没办法,只有现学现卖,又回到Linux的怀抱了.今晚想配置一下LAMP环境,但是之前用的6.6,今晚想闷声做大死,用一次7试试.网上找了很多教程,但是好像转载的都不负责任,有些到下一步之间直接就报错了.稀奇古怪的错.今晚记录一下LAMP的,方便以后自己查看. 安装常用工具 Rsync yum -y install rsync vim yum -y install vim 配置免密码登陆ssh服务器 参照我基友的博客 安装LAMP 尽管你在百度随便一搜就能搜到大量的配置教程,但是

Java内部类的使用小结

内部类是指在一个外部类的内部再定义一个类.类名不需要和文件夹相同. *内部类可以是静态static的,也可用public,default,protected和private修饰.(而外部顶级类即类名和文件名相同的只能使用public和default). 注意:内部类是一个编译时的概念,一旦编译成功,就会成为完全不同的两类.对于一个名为outer的外部类和其内部定义的名为inner的内部类.编译完成后出现outer.class和outer$inner.class两类.所以内部类的成员变量/方法名可

在浏览器端用JS创建和下载文件

前端很多项目中,都有文件下载的需求,特别是JS生成文件内容,然后让浏览器执行下载操作(例如在线图片编辑.在线代码编辑.iPresst等). 但受限于浏览器,很多情况下我们都只能给出个链接,让用户点击打开->另存为.如下面这个链接: <a href="file.js">file.js</a> 用户点击这个链接的时候,浏览器会打开并显示链接指向的文件内容,显然,这并没有实现我们的需求. HTML5中给a标签增加了一个download属性,只要有这个属性,点击这

Java内部类的使用小结 形参为什么要用final

部类是指在一个外部类的内部再定义一个类.类名不需要和文件夹相同. *内部类可以是静态static的,也可用public,default,protected和private修饰.(而外部顶级类即类名和文件名相同的只能使用public和default). 注意:内部类是一个编译时的概念,一旦编译成功,就会成为完全不同的两类.对于一个名为outer的外部类和其内部定义的名为inner的内部类.编译完成后出现outer.class和outer$inner.class两类.所以内部类的成员变量/方法名可以

Java内部类的使用小结(转)

内部类是指在一个外部类的内部再定义一个类.类名不需要和文件夹相同. *内部类可以是静态static的,也可用public,default,protected和private修饰.(而外部顶级类即类名和文件名相同的只能使用public和default). 注意:内部类是一个编译时的概念,一旦编译成功,就会成为完全不同的两类.对于一个名为outer的外部类和其内部定义的名为inner的内部类.编译完成后出现outer.class和outer$inner.class两类.所以内部类的成员变量/方法名可

用JS在浏览器中创建下载文件如下可以做到

前端很多项目中,都有文件下载的需求,特别是JS生成文件内容,然后让浏览器执行下载操作(例如在线图片编辑.在线代码编辑.iPresst等 但受限于浏览器,很多情况下我们都只能给出个链接,让用户点击打开->另存为.如下面这个链接: <a href="file.js">file.js</a> 用户点击这个链接的时候,浏览器会打开并显示链接指向的文件内容,显然,这并没有实现我们的需求.HTML5中给a标签增加了一个download属性,只要有这个属性,点击这个链接

Python程序猿必知会的Django用户模块扩展方法

本文和大家分享的主要是Django用户模块的扩展相关知识,希望可以帮助大家更好的学习Django ,一起来看看吧. Django内置的用户验证系统十分强大.大多数情况下,它可以拿来就用,能帮我们省去很多开发.测试的工作.它能满足大多数的使用情况并且很安全.但是有时候,为满足我们的网络应用需求,需要对它进行一些微调. 一般来说,我们希望更多地存储与用户有关的数据.如果你的网络应用具有社交属性,你可能希望存储用户简介.地理位置以及其他相关的东西. 在此教程里,我将简单呈现扩展Django用户模型的方