
着手开始基于微信小程序的APP开发
虽然我对《又大又杂的APP》充满了厌恶,但既然已经答应了朋友,无论如何也只好硬着头皮开始了这个微信小程序的开发。才开始两天,就发现真的是太痛苦了。整个项目杂乱、庞大,而且连基本的规则都是混乱的。 它期望利用微信小程序完成一个SNS社交平台类应用的构建,这几乎就可以看作是痴人说梦,甚至可以说是“梦中梦中梦”。 微信其实就已经是“梦中梦”了,原本微信只应是一个IM工具,而诸如社交、分享、朋友圈的功能,应该是分散在手机系统的各个APP中,然而微信却将这所有的功能整合到了一个应用中,好像在手机系统中嵌入了一个子系统,加之微信提供的公众号、服务号、小程序等扩展能力,它真的可以完成“梦中梦”的实现。 然而我那个朋友想做的APP,是一款宠物兴趣人群的SNS应用,但他却只想在微信的小程序中实现,他的理由很简单:小程序开发成本低、推广起来用户基础好。 但是他想做的本身也是一个平台级应用,例如:这个应用是具有SNS属性的、拥有SNS属性就意味着有好友关系、好友之间能够进行短信短消息的交换…… 如此一来,相当于你打开手机之后想分享一个照片,不需要使用手机中的、成熟的SNS社区,只要进入微信那个“子系统”就可以操作了。 而当你想将自己的猫咪日常生活分享给你的“猫咪好友”时,这个好友其实即不再某个SNS平台中、也不再微信中、而是在微信的小程序的某个小程序服务商列表中,于是你就要:打开手机、进入微信、启动小程序,使用这个小程序APP分享照片。这不就是“梦中梦中梦”么? 我自己的电脑性能差、手机性能也很差,所以平日中我使用微信都比较费劲、卡顿的,有些时候去商场买东西必须使用店家的小程序时我总会皱眉——几乎可以肯定很难快速启动他们的小程序,几乎可以肯定大概率会加载慢、崩溃。而那些商家的小程序其实功能还算简单、页面也不复杂呢。 我现在都可以想象出朋友那个宠物SNS小程序,果真实现出来之后将会何其缓慢、问题重重。 事实上,它很可能实现不出来,因为是我在开发这个APP呀,我的电脑老旧得甚至连开发者工具都运行不起来。只一个非常简单的页面组件的开发,都会崩溃好几次。所以两天下来,连一个页面都没有完成。如此缓慢的进度,想实现出来?又是有点儿“痴人说梦”了。 开发过程的技术细节我觉得到没什么太多可以记录的,至少现在还没有遇到值得记录的内容。毕竟现在刚刚开始,只是做了一些基本的页面,而这些页面也就只是html代码和css样式的编写,其中不存在什么高新技术。 如果往后的日子里,这个项目能够持续开发,并且真能向着最终目标一点点的前行,那我就将开发过程中遇到的问题、值得写上几笔的地方,当作日记记录在这里,也方便自己今后回顾这段“痛苦不堪”的帮忙经历吧。
辗转相除法计算两个数的最大公约数
本来想做一个在线的一元二次方程求解小工具,但是真的上手操作才发现,想法很简单、实现起来很麻烦。所以我只好不断的简化需求,经过几次简化现在只能先完成对分数的化简操作,也就是在给定一个分数之后,对这个分数进行约分得到最简分数。 其中用到了一个求两数最大公约数的方法——辗转相除法。 实际上想计算两个数的最大公约数,有几种不同的方法,其中辗转相除法是相对容易理解、也比较容易通过程序实现的。 这里是最终完成的效果演示: https://www.m3we.com/mathtools/gcd.php?numerator=3334&denominator=12 即便是这个简单的功能,现在的演示也仍然不够完善、不够完美,还有很多需要进一步完善的地方。所以对于求解一元二次方程,短期内是难以实现的,只有一步步的先将这些基础环节做好,之后再做打算了。 update 2024.07.13 自己试了几个,发现还是存在bug的,例如下面这个计算过程,就是不正确的,原因还没有推敲,估计还要几天才能解决。 https://www.m3we.com/mathtools/gcd.php?numerator=333143543545.12&denominator=124.32 update 2024.07.14 18:51 已经找到了上面bug产生的原因,并且初步解决了。这里欠着一篇关于这个bug的记录,额外的又发现了一些新的问题,例如对于如下的分数,最后的表现也不尽人意,所以这个小工具还是有很多要改进的地方: 1、如果分子或分母中有符号,则在最终的结果中,应该将符号提取到整个分数的外面: https://www.m3we.com/mathtools/gcd.php?numerator=-333&denominator=33 2、如果分子和分母中同时有符号,虽然最后的结果是正确的,但是这只是计算的结果,与思维的过程实际上是不同的。正确的思维过程应该是先完成(增加一步预处理)变号操作: https://www.m3we.com/mathtools/gcd.php?numerator=-333&denominator=-33
我对又大又杂的APP一点兴趣也没有
朋友拜托我做一个新的网络应用,是要基于小程序进行开发。但是我看了一下原型设计,又大又杂。本来只是一个很小的网络服务,非要做的好像一个门户、好像一个社区一样,臃肿无比,这是令我反感且毫无兴趣的。 如果不是因为抹不开面子,我是一定不会做这样的门户级应用的。原因在于:你做的像个门户,却没有足够多的内容支撑其内容,有没有足够的技术支撑其底层,最后就一定会烂尾。即便有足够的内容和技术将它强行的承托起来,但这样的门户感给人的感觉就是专业和庞大,这种“装”出来的庞大,如果没有真实的用户基础,依然会在运营过程中渐渐的枯萎、最终无疾而终。 所以这样的项目基本上是三岁看老,一眼就能看到头的。 我更喜欢小巧的、纯粹的、单一的服务,一个事情就是一个功能,一个功能就是一个应用。但这样形态的产品现在好像不吃香,至少在我生活的地方不吃香,大家都更喜欢大而全。 花里胡哨的华丽,是他们更喜欢的,在他们看来这才叫“应用”。这样的应用我曾经不知道做过多少,但这么多年下来,一个活着都没有,导致我在自己的“成功案例”里面完全是空白的。有的时候甲方会问我为什么没有成功案例,我怎么回答呢?全都死掉了?如果这样回答,甲方一定会觉得我做的不行、或者我骗人其实从来没有做过,所以最终谈项目的时候会荒掉。 如此陷入的就是恶性循环,累死累活不说,还总也没有拿得出手的东西,没有成功的作品。但事实就是这样。 这次朋友找到我,我就和他说的十分明白,一定要小而精,一定要纯粹。他答应的好好的,结果今天原型图出来给到我,我头就大了。这那里是小而精了? 产品原型规划中,仅仅APP端的业务页面就有173个,还不计后台、接口层,只是单纯的前端数据展现页面,不是那种可以复用的、而是彼此毫无无用关系的,每个页面都是独立功能的,整整173个不同的数据类型和相关的展现页面!!! 除了慢慢的一屏幕的SNS味道,还有无数的通栏广告位,还有各种点赞与收藏的机制,还有分享,还有开屏广告……这不是小程序,这活生生的又是一个巨大的门户网站啊! 没有办法,只能硬着头皮答应朋友做。2个月之后交工。这个工期其实也十分的扯,因为我们约定的是个“小程序”,所以2个月其实时间上都比较长了。但实际上他最终要的东西是个门户,我内心估计至少需要4-6个月才能有个模样。可是当我说出需要3个月的时候(这还是我咬着牙说出来的),朋友已经瞠目结舌,问为什么一个“小程序”需要那么长的时间? 这种尴尬的时刻,再多的解释其实都没有意义,解释的多了反而徒增烦恼,所以我就垂头丧气的告诉他那就加加班、2个月做出来吧。其实看得出来,当他听到“2个月”时,还是觉得太久了,但朋友终究没有再压缩时间,只是说尽量赶。我心想:这样赶出来的,能是什么狗熊样子呢? 翻翻自己曾经做过的项目,拿一个差不多的出来给他改吧,反正这个项目我也不看好。如果真的能够(几乎不可能)做出一些客户和流量来,我再对细节进行返工就是了。但我现在的估计是——指不定又是那个天使倒霉蛋儿,要亏钱了。